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ABSTRACT 


There is a need for a standard, accurate test bench for 
inertia-based orientation sensors. Static accuracy testing 
of these sensors is straightforward but dynamic accuracy 
testing is more difficult. A test bench system is developed 
with encoders and a PC104 computer under the QNX Neutrino 
real-time operating system. A MicroStrain 3DM-GX1 inertial 


sensor was used as the sensor to be tested. The dynamic 





error of this sensor was accurately recorded and found to be 





a function of the sensor velocity and acceleration. 
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EXECUTIVE SUMMARRY 


The purpose of this project was to develop a control 
systems environment complete with encoder capabilities on a 


PC104. This system’s capabilities were tested by using it 





to measure the dynamic accuracy of the MicroStrain 3DM-GX1 
orientation sensor against the benchmark of an encoder. The 
digital input/output and the digital-to-analog conversion 
circuits and the RS-232 port of the PC104 were used to 


accomplish this task. 


In this project, a Diamond Systems Prometheus PC104 
with a data acquisition circuit was used as a target 
machine. The main encoder used was a 16-bit absolute 
encoder by Gurley Precision Instruments. The encoder 
communication and control was performed with the digital 


inputfoutput circuit. The MicroStrain 3DM-GXl sensor 





communications all occurred through the RS-232 port. The 


MicroStrain sensor was attached to the end of a wooden 








pendulum and th ncoder served as the pivot point of this 
pendulum. This allowed the angles of the two sensors to 
move synchronously with one another. The pendulum was set 





in motion and the position of the two sensors were recorded 


and output to a MATLAB compatible file. 


The results yielded an error of the MicroStrain sensor 
well within the specifications established by the company. 
The worst error was 1.3019° when the pendulum was at a 


length of one foot. It was discovered that the error is a 





function of the velocity, acceleration, and flexure of the 





pendulum. 
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I. INTRODUCTION 


A. MOTIVATION 


The motivation for this thesis originates from two 
different driving sources, the need for a PC104 controls 
environment at the United States Naval Academy and the need 
for a standard, accurate test bench for inertia-based 


orientation sensors. 


Currently, the United States Naval Academy Systems 





Engineering Department uses the Rabbit 2000 microprocessor 
as a control systems platform. This system has many 


limitations that create the need for a newer, more powerful 





system. The first major limiting factor of the embedded 





systems the school currently has is the limit of control 





routine execution rate. The systems currently used are not 
able to execute control routines any faster than 
approximately 1 kHz. This speed is fast enough for most 
routines used but there are many new routines that could be 
executed if the control routine could execute at a faster 


rate. Other limiting features include difficulty 








interfacing with MATLAB, communication speed, portability, 





and minimal data storage. A PC104 with a data acquisition 
circuit would be the solution. For this system to be 


incorporated into that classroom at the Naval Academy, the 





complexities of the inter-circuit and inter-system 
programming must first be reduced into simple user-friendly 
function calls. A class of functions that operate the 


digital to analog converters, analog to digital converters, 








digital input/output, and encoder input are necessary. 





Without this type of function library the students would 


need a much mor xtensiv knowledge base in computer 





programming and operation. A complied function library will 


allow users with basic computer programming knowledge to 





program a complex control routine on the embedded system. 


The second source of motivation is more of an industry 
wide source. There is a need for a standard, accurate test 
bench for inertial sensor units, as Yun and Bachmann 


identified in Ref. 1. The MARG project at the Naval 





Postgraduate School shows a 9° error between the inertial 





sensor and the test bench. [1] The paper in reference 


indicates the error is greatest during the dynamic motion 














periods. One of the problems is the test bench does not 
give output of the angle. The test apparatus can only be 
set to turn to specific angles. The intermittent position 
information is not available. This means the position of 
the test bench must be modeled. In the case of reference 1, 
the test bench motion is modeled as linear motion. This is 

















not a correct model because the test bench must accelerate 
and decelerate. The lack of this information could be the 


cause of the error discovered. Creating a test bench that 





is capable of recording or outputting intermittent position 





information would eliminate this problem and the error from 
this problem would be reduced, allowing the analysis of the 


sensor to be more accurate. 


The MicroStrain 3DM-GXl sensor is an inertial-based 
orientation sensor that could be used in the project of 
reference 1. This sensor has been used in human motion 


tracking in other projects[2]. To model and track the 








information more accurately the error of the sensor would 


have to be known. The MicroStrain company does not 


distribute any information about the sensor operation with 





respect to the dynamic motion, besides the dynamic accuracy. 





It is not known exactly how accurate the sensor is during 
motion. Static accuracy can be easily determined by keeping 


the sensor still and reviewing the output data. Dynamic 





accuracy is harder to measure because the sensor position 


has to be measured while in motion. An accurate test bench 








system must be created that will allow the position 


measurement and the sensor readings to be correlated as 





closely as possible. An encoder in conjunction with a fast 


and powerful control system would allow this analysis. 
B. GOALS 


The main goals of the project are: 


e Develop a user-friendly controls environment on a 
PC104, complete with data input and output. 











e Develop and create a test bench for inertia-based 
orientation sensor. 


e Develop an interrupt service routine that will 
service the serial universal asynchronous receiver 
transmitter, compatible with the RS-232 standard. 











e Test the dynamic accuracy of the MicroStrain 3DM- 
GX1 orientation sensor. 


Cc. CHAPTER DESCRIPTIONS 


Chapter I is the introduction and motivation for this 





project. 

Chapter II discusses most platform specific 
information. It gives a background and description of the 
PC104 used in this project. It also describes the QNX 
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Neutrino operating system and a short introduction to what a 


real-time operating system is and why this project requires 





such an operating system. 


Chapter III describes in detail all the apparatus used 


or developed in the project. It discusses the host machine, 





the target PC104 input, output, and boot indication program, 





the MicroStrain 3DM-GX1l sensor, the encoders used in the 


project and finally the pendulum constructed. 


Chapter IV describes all the test related information. 





This chapter is where the actual setup of the apparatus is 


discussed. A complete description of the data acquisition 





program and the attached interrupt service routine is 
included. The chapter finishes with plots and explanation 


of all the results. 


The final chapter, Chapter V, contains the conclusions 


and the recommendations for future work. 


Appendix A is a complete version of the 16-Bit encoder 


program used to record the MicroStrain 3DM-GX1l_ sensor 





dynamic error. Th ntire code was written in Ctt. 


Appendix B is a complete version of the control.wse 





file which contains many of the functions created and used 


in this project. 


II. PLATFORM INTRODUCTION 


A. THE PC104 


dy. Introduction 


The heart of this project is a PC104. It is the system 


that controls and records all information needed to make 





observations and calculations. The PC104 interacts with the 





apparatus to be tested through digital input/output (DIO) 
ports, analog to digital converters (ADC), and digital to 


analog converters (DAC). 


2. Background 


The PC104 technology was first created in 1987 by Ampro 





Computers. [3] This company was founded in 1983 for the 
purpose of manufacturing compact single board computers to 
be used in embedded systems. The MiniModule was the first 
PC compatible embedded system with the capability of modular 


expansion. For the purpose of this thesis PC refers to 








Personal Computer, a term and standard developed by the IBM 





company. The form factor of the MiniModule is one of the 





features that classified it as the first PC104. The actual 








board measured 3.6 inches by 3.8 inches, which is now the 


PC104 form factor. [3] 


Even though the first PC104 was produced in 1987 it was 
not a common system in the embedded control industry until 
the PC104 Consortium was founded by 12 companies in February 


1992.[4] A month later, in March 1992, the PC104 Consortium 


published the “PC104 Specifications” which established and 


launched the vast popularity of this new standard. [4] 


The PC104 gets its name from some of its more 


distinguishing specifications. The system is compatible 





with any computer compatible with the PC standard introduced 





by IBM. The second part of the name is derived from the pin 
specification for inter-module communication. There is a 


set configuration of 104 pins which enables communication 





between the CPU module and any other module. 


3. Prometheus PC104 


The PC104 used in this project is a Diamond Systems 





Prometheus PC104. It was selected because it has a powerful 
data acquisition board packed with it. The operating system 
is the QNX Neutrino 6.2.1 real-time OS. It has an internal 





6 GB hard drive connected to the IDE port. The hard drive 





has a separate power supply and is not housed within the 
vendor supplied PC104 casing. The hard drive is too large 
to fit inside. The OS was loaded onto the hard drive while 


it was connected to anther desktop PC. This method of 





loading the OS was easier than connecting a CD-ROM directly 
to the PC104. Once the OS was loaded, the hard drive was 
connected to the PC104. 


The specifications of the PC104 were taken directly 


from the Prometheus CPU user manual in Ref. 5: 


Processor Section 


@ 486-DX2 processor running at 100MHz with co- 
processor 


#¢ Pentium class platform including burst-mode SDRAM 
and PCI-based IDE controller and USB 


@¢ 32MB SDRAM system memory 
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I/O 
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4 
4 
4 


50MHz memory bus for improved performance 





2MB 16-bit wide integrated flash memory for BIOS 
and user programs 





8KB unified level 1 cache 





4 serial ports, 115.2kbaud max 





2 ports 16550-compatible, 2 ports 16850-compatible 
with 128-byte FIFOs 





2 full-featured powered USB ports 





1 ECP-compatible parallel port 
Floppy drive connector 


IDE drive connector (44-pin version for notebook 
drives) 


Accepts solid-state flashdisk modules directly on 
board 


100BaseT full-duplex PCI bus mastering Ethernet 
(100Mbps) 


IrDA port (requires external transceiver) 








PS/2 keyboard and mouse ports 
Speaker, LEDs 


System Features 


¢ 
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Plug and play BIOS with IDE autodetection, 32-bit 
IDE access, and LBA support 








Built-in fail-safe boot ROM for system recovery in 
case of BIOS corruption 





User-selectable COM2 terminal mode 


On-board lithium backup battery for real-time- 
clock and CMOS RAM 


ATX power switching capability 
Programmable watchdog timer 
Power surge monitor for fail-safe operation 


Zero wait-state capability for flash memory and 
PC/104 bus 





+5V-only operation 





¢ Extended temperature range operation (-40 to 
+850C) 


¢ Cable-free operation when used with Diamond 
Systems’ PNL-Z32 Panel I/O board 





The PC104 also has a data acquisition circuit for I/O 








operations. This circuitry communicates with the PC104 
through the ISA bus. The circuit diagram of the Prometheus, 


which depicts this circuit, is seen in Figure 1. More 





details of the data acquisition circuit are discussed in a 





later chapter. 


PROMETHEUS BLOCK DIAGRAM 


ZFx86™ 
PROCESSOR 
2USB 
WATCHDOG 1/0 


PCI BUS 


ga LE MAGNETICS ETHERNET 


PROGRAMMABLE 
GAIN 


DATA 
ACQUISITION 16-BIT A/D INPUT 


CONTROLLER 


4 ANALOG 
OUTPUT 
12-BIT D/A 
24 DIGITAL 
ISA-PC/104 BUS yo 





Figure 1. Prometheus PC104 Block Diagram [From Ref. 5]. 


A photo of the actual PC104 used in this project is 


seen in Figure 2. 





Figure 2. Actual PC104 Used in the Project. 


B. THE QNX OPERATING SYSTEM 


1. Introduction 


The operating system (OS) that was used for this 
project was QNX Neutrino Real-Time Operating System (RTOS) 








version 6.2.1A. It is bundled with the QNX Momentics 
Professional Edition Integrated Development Environment 
(IDE). This operating system was chosen because it is a 





real-time OS and it was free through an education grant 


given by the QONX Software Systems Company. 
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2. QONX Neutrino RTOS v.6.2.1A 


The QNX Neutrino v 6.2 was developed and released in 
2002. ONX was founded in 1980 and since then has been the 
leader in the industry of real-time microkernel operating 


systems. [6] The real-time microkernel aspect of the OS is 





vitally important to the application described in this 


thesis. A deterministic execution of code under an RTOS 





allows the recording and syncing of the measurements between 


two different I/O devices to be as close as possible. 


One of the main advantages of an RTOS is its 
predictability. An RTOS is designed to guarantee the 


execution of a computation in a reasonable amount of time if 





there are no external influences, such as interrupts. Since 


external influences such as interrupts can be disabled, the 





programmer has the ability to ensure a deterministic 





execution environment by implementing the proper setting. 
This may be disabling all interrupts or at least controlling 
necessary interrupts. This extent of control ensures that 





any delays in a system are not caused by the OS. [7] 


The deterministic timing and execution of instructions 





relies partly on the scheduling scheme of the OS. A 


prioritized system of scheduling must be utilized. Higher 








priority items must be allowed to execute before lower 





priority items. This is a necessity for an RTOS. This 
gives the OS a way to ensure that all real-time sensitive 


instructions are actually executed deterministically. A 





real-time thread or process would be assigned a higher 





priority to ensure that it is executed when it needs to. 


The only thing that would be able to potentially interrupt 





this execution would be a system call. [7] 
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Priority inversions must also be controlled in an RTOS. 
This is where a high priority thread is trying to use a 
resource that is already allocated to a low priority thread 


and a medium priority thread is executing. In this case, 





the low priority thread would not be allowed to complete and 


fre th resources until the medium thread resource is 





completed first. This would cause many problems with the 
system and cause the system to lose its real-time 
characteristic. High priority threads are usually threads 
designed to run real-time. If the thread has to wait for 
lower priority threads to complete first, timing of the high 
priority thread would no longer be guaranteed. To ensure a 
system is real-time, priority inversion must be controlled 
in such a way that a real-time thread will never have to 


wait for a lower priority thread. This is either 





accomplished by the lower priority thread giving up the 
resource or the lower priority thread taking on the higher 


priority’s priority through priority inheritance. [7] 








Another requirement for a real-time operating system is 


for the system to have a periodic division of processor time 








that can be allocated to processes. A portion of this time 


must be reserved for real-time processes. It must also 





ensure that non-schedulable instructions, such as 





microkernel calls, must not violate this time limit. When 





any instruction executes, whether it is in a kernel call, a 





real-time activity, or non-real-time activity, if it takes 














more than the predetermined period of time it starts to 


affect the characteristics of a real-time system. No longer 

















are all execution times guaranteed becaus real-time 
processes are not able to execute when expected. This is 
true even for other real-time processes. If there are two 
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real-time processes running at the same time, they must 


equally share the time on the processor. If they do not, 





one of the processes will start to show non-real-time 





characteristics becaus the execution will not start when 





expected. Under an RTOS, programs are designed to run on a 








strict schedul because th tim between xecutions 





critical for some particular reason. [7] 


is 


Steve Furr develops five critical system requirements 





for an RTOS in his paper What is Real Time and Why Do I Need 


It? from Ref. 7: 


1 The OS must support fixed-priority preemptive 
scheduling for tasks (both threads and processes, 
as applicable). 





2 The OS must provide priority inheritance or 
priority-ceiling emulation for synchronization 
primitives. 





3 The OS kernel must be pre emptible. 





4 Interrupts must have a fixed upper bound on 
latency. 


a. By extension, support for nested 
interrupts is required. 





5 Operating system services must execute at 
apriority determined by the client of the 
service. 


a. All services on which the client is 
dependent must inherit that priority. 





b. Priority inversion avoidance must be 
applied to all shared resources used by the 
service. 


Requirement 1 indicates that scheduling must be fixed 





priority and preemptive. A scheduling priority 





is 


definitely needed, as discussed earlier. The fixed priority 





is a more well-defined requirement. It is required to be 


fixed so that there is a set standard and structure for the 
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programmer to follow when designing a real-time program and 
application. This standard fixed priority allows’ the 
programmer to run the program at a known priority, allowing 
real-time execution. The second half of this requirement is 


also very important. If a lower priority process is taking 





too long, or a higher priority process must execute, then 








there must be a way for immediat execution. This is 





accomplished with the preemptive nature of the scheduling 


routine. Preemptive scheduling allows the operating system 








to halt a currently running process or thread and execute a 


higher priority process or thread, after which it restores 











the state of the halted process or thread and it is able to 


continue execution. This is important because it is another 





characteristic of the OS that ensures the timing guarantee 


of an RTOS. 


Requirement 2 was discussed earlier in the paper. 


Essentially, there must be priority inheritance to avoid a 





priority inversion condition. 


The third requirement further extends the bounds of the 
first requirement. The kernel is a type of layer that 
allows interaction between system critical hardware and the 
programs. It controls communication between programs and 


hardware such as the CPU, memory, and other devices. Since 








is it conceivable that many programs will have some type of 
interaction with one of these system critical hardware 
devices, it makes sense that the kernel must have preemption 
capabilities. If a real-time process relies on a kernel 


call for proper real-time execution, the kernel must be able 
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to preempt a currently running process or thread. This 
helps to guarantee discrete execution of the real-time 


process or thread. 


The fourth requirement is needed to limit the invasion 
of interrupts. In real-time operating systems, interrupts 
are very important. In many applications, interrupts are 


used to guarantee the operation is performed at a real-time 





pace. This will be the case in this project. The majority 
of the program is run by interrupts. If the interrupts are 
processed instantly and are not very complicated, the system 


will operate at a predictable, deterministic rate. For 





interrupts to occur in a real-time OS and not affect the 














real-time characteristic, the interrupt handler must respond 
quickly. This is the reason to place an upper limit on the 


latency. 





The final requirement extends the earlier discussion 
about priorities of the OS services. Under a real-time OS, 
all processes, thread, and operations must execute in a 


controlled, deterministic manner. 


The ONX Neutrino OS has all of the characteristics. 





This means if a program is created and run properly, it will 





run in real-time. This is crucial for this project becaus 


the exact time and sensor positions must be recorded. Tf 





there is any delay in the program the time and the position 
may not correlate. In this project there are two sensors 
being read and correlated with time and position, so it is 


even more vital that the program runs in real-time. 


The entire program will be written in C++ with the QNX 


Momentics IDE. When the programs are compiled they will 





execute on the target PC104 system that will be in constant 
14 


communication with the host Momentics instance through the 
Ethernet connection. Specific aspects of the communication, 
the program code, and execution will be discussed in later 


chapters. 
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IIIT. THE APPARATUS 


A. HOST MACHINE 


The QNX programming is all performed on a host machine. 








This is necessary because th target machine, the PC104, 





does not have enough memory to run the QNX Momentics 


Integrated Development Environment (IDE). The PC104 only 





has 32MBs of RAM and the IDE reguires far more than that. 
QNX recommends 256MB of RAM. The PC104 uses 19MB of the RAM 
just for the QNX operating system to run. When the IDE is 
launched on the PC104, the memory is maxed out and the IDE 





will quit loading during its startup phase of loading. The 





memory is then freed of the partially loaded program. The 


target’s processor is only 100MHz which would also limit the 








productivity of the system. While processor speed will not 
necessarily stop the program from loading or working 


correctly, the program will most likely run so slowly that 





productivity would be severely limited. 


The host machine is a Dell Dimension 8100 with an Intel 





Pentium 4, 1.70 GHz processor and 2GB of RAM. It uses a 3- 





Com 100 Base-T Ethernet Card for host to target 








communication. The only input devices used are a mouse and 
keyboard and the only output device used is the VGA output 


of the on-board graphics card. This is all exclusive of the 





i/O Ethernet: -card's This Dell system has an on-board 
Ethernet card that has been disabled in the BIOS to decrease 


the likelihood of hardware conflicts. 


17 


B. TARGET MACHINE - PROMETHEUS PC104 


The target machine is the PC104 described a previous 
chapter. This target machine is the location where all the 
developed code is actually run. The QNX Momentics IDE can 
be set up to communicate between the host and target 


directly through the Ethernet connection. 


1. Unidirectional Input Devices 


While the PC104 is capable of using a mouse and 
keyboard as input this particular setup does not include 


either. The purpose of this project is to have a PC104 that 








is entirely remote operable. A mouse and keyboard would 





serve no purpose in a remote application as the user would 


not have access to them. The PC104 does not use the USB 





ports because all peripherals are accessed through other 





pores. 


2. Unidirectional Output Devices 


The PC104 does have a VGA adapter card but this card 





was not used for any step other than the initial set up of 





the PC104. There are some applications where a VGA monitor 





may be useful but because this PC104 setup is designed to be 
operated in a remote environment, most likely the user will 


not be able to be in the same location of the monitor or the 





system will not be able to support the monitor. Many remote 


applications of this PC104 will not be able to support a 





monitor because of the power requirements. Many of the 


applications of this PC104 require the lowest possible power 





draw of the system. Monitors will increase system power 


requirements while not adding much benefit to the system. 
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If a user is in the same location as the PC104, the user 
will be able to remotely log in to the system. for 
diagnostics. When executing code from the host machine, all 
console output is directed to the host machine erasing the 


need for a monitor as a console out for program execution. 


There is one instance when a monitor would be very 
useful, that is the boot phase of the PC104 startup. Since 


the PC104 only has a 100 MHz processor, it takes much more 





time to boot to the user screen than a modern day personal 


computer does. Without a monitor it is very difficult to 





know exactly when the machine has finished booting up. A 
monitor would obviously be one solution to this problem. 
Since this project aims to decrease all power consumption a 


new boot completion technique must be used. The solution 





was to develop an LED indication of when the system has 





finished booting. 


a. Boot Completion Indicator 


The boot completion indicator output is driven by 





the parallel port. For this PC104 the parallel port is set 
at location 0x378. The indicator is a set of eight red LEDs 
that are driven from the power supplied by the port. Each 





LED is driven by one of the eight data output ports of the 


parallel port. On a standard 25-pin parallel port the data 





output is seen on pins 2-8. Ground can be connected to any 
pin between pins 18-25. This project uses pin 18 for 


ground. The circuit includes a resistor between the LED and 





the positive end of the supply, as seen in Figure 3. The 
resistor is there to limit the amount of current that flows 


through the LED. 
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Figure 3. LED Circuit for boot completion indicator. 





LEDs have very low internal resistance and without 
a resistor an LED could draw enough current to either damage 


itself or damage the parallel port hardware. An array of 





eight LEDs that are all individually controlled by a 
separate output line of the parallel port was the method of 


choice because this helps to decrease false indication of 
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the system state. If only one LED was used there would be a 





higher risk involved that either the LED burned out or that 











particular data line is faulty. Including all eight 





available lines and eight LEDs lowers the risk that the 


output, either an LED on or off, of the overall system is 








faulty. A completely faulty indication, in the one LED 
system or the eight LED system, will decrease system 


reliability because the user will not know for sure whether 





the system is fully booted or not. 


The program that was used to operate this 


circuitry is listed below: 





#include <unistd.h> //for delay() 
#include <hw/inout.h> //for out8&() 
#include <sys/neutrino.h> //for ThreadCTL() 


No& MH 
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5 int main() 

6: { 

7 //GAIN ROOT PERMISSION FOR I/O CONTROL 
8 ThreadCTL (_NTO_TCTL_IO, NULL) ; 

9: for(int 1=0;1<10;i++) //FOR 10 ITTERATIONS 
10: { 

Lol out 8 (0x378,0); //All LEDS OFF 

12: delay(100); //DELAY 100ms 

13s out 8 (0x378,255); //ALL LEDS ON 
14: delay(100); //DELAY 100ms 

Ls } 

16: return 1; 

TALE Ap 


When the program starts it needs to get root 
permission to perform I/O operations. This is accomplished 
y the call to ThreadCTL() at line 8. This function is 
specific to the QNX Neutrino operating system. Once the I/O 
permission is obtained the program continues. The for loop 
started at line 9 gives the indicator the functionality to 


Signal exactly when the OS is fully loaded by blinking ten 





times. This task is accomplished by the blinking cycle 
contained within the for loop. The call to out8(0x378, XXX) 








at lines 11 and 13 send an 8 bit output byte to the parallel 
port found at location 0x378. The second parameter of the 
function is the value of the 8-bit word that is sent. Zero 
is binary 00000000, meaning all the LEDs will be off because 


all outputs are low (0). Line 13 sends 255 which is 











11111111, turning all the LEDs in the array on because all 








bits of the parallel port data output are high (1). When 
the output is high it outputs 5V, enough to turn the LEDs 
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on. When the program completes execution, all LEDs are left 
on because the last data packet sent to the parallel port 


was 255. This constant burning LED array indicates that the 





PC104 is fully booted and the user may start executing other 


programs. The array in this state can be found in Figure 4. 





Figure 4. Boot Completion Indicator. 








The LEDS will remain on as long as the user does 
not modify the port within a program. The operating 
system’s interaction with the parallel port is stopped just 
before the start up indicator program is started. The OS 
startup script is located at /ect/re.d/re.sysinit. TO 
ensure proper operation of the boot indication program the 
line slay devc-par must first be included in rc.sysinit. 
This disconnects the OS handle to the parallel port. Tete 


this process is not killed, the OS may interfere with the 
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proper operation of the program, or the lasting effect of 


continuing the LEDs in the on state. The next line that 





must be added to rc.sysinit is startind. This line tells 








the OS to start the boot completion indicator program 
execution. This is how the proper startup of the OS can be 


indicated to the user without the use of a monitor. 
3. Bidirectional Input/Output Devices 


There are four main devices on board the PC104 that are 





bidirectional I/O devices. They are the serial 





communications device, data acquisition circuit, Ethernet 








communications device, and the universal serial bus (USB) 





device. The USB ports were not setup or used because they 


serve no immediate benefit to the project. 





a. Ethernet Port and IP Address 





The Ethernet port was established on the target 


with a static IP of 192.168.0.2. Creating a static IP 





address instead of a dynamic IP address allows the system to 








mesh more easily. If the IP of the target was not static, 





the user would have to find a way to retrieve the IP 








address. With no keyboard or monitor in the system it would 





be difficult to retriev th IP address if it were 





dynamically assigned by an outside device. Therefore, 


assigning a static IP address is more reliable. 


b. RS-232 Serial Port 


The PC104 system has four RS-232 serial ports on 
the I/O module. Serial port 1 was used for the 





communications between the PC104 and the MicroStrain sensor. 


The other ports were not needed. The serial port 1 (COM1) 
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is built into the ZF Micro CPU chip on the PC104 module. It 
is a 16550 standard serial universal asynchronous 
receiver/transmitter (UART) with a 16-byte first-in-first- 


out buffer.[5] Actual communications of this device are 





discussed in a later chapter. 
c. Data Acquisition Circuit 


The data acquisition circuit is part of the 
Prometheus PC104 package. This is the device that 
performs all of the digital input/output. This circuit is 





also capable of analog to digital conversions and digital to 
analog conversions. The complete list of specifications are 
seen below. This list was taken from the Prometheus User 
Manual, Ref. 5. 


Analog Inputs 




















No. of inputs 8 differential or 16 single-ended 
(user selectable) 

A/D resolution 16 bits (1/65,536 of full scale) 

Input ranges Bipolar: +10V, +5V, #2.5V, +1.25V 
Unipolar: 0-10V, O-5V, 0-2.5V 

Input bias current 50nA max 

Maximum input voltage +10V for linear operation 

Overvoltage protection +35V on any analog input without 
damage 

Nonlinearity +3LSB, no missing codes 

Driite 5PPM/oC typical 

Conversion rate 100,000 samples per second max 

Conversion trigger software trigger, internal pacer 
clock, or external TTL signal 

FIFO 48 samples; programmable interrupt 
threshold 

Analog Outputs 

No. of outputs 4 

D/A resolution 12 bits 41/4096 of full seale) 

Output ranges Unipolar: 0-10V or user- 


programmable 

Bipolar: +10V or user-programmable 
Output current +5mA max per channel 
Settling time 4uS max to +1/2 LSB 
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Relative accuracy 
Nonlinearity 
Digital I/O 

No. of lines 
Compatibility 


Input voltage 





[Input current 
Output voltage 




















Output current 


I/O capacitance 
Counter/Timers 

A/D pacer clock 
Pacer clock source 
General purpose 

GP clock source 
General 

Power supply 
Current consumption 


Operating temperature 





Operating humidity 








+1 LSB 

+1 LSB, monotonic 
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3.3V and 5V logic compatible 
Logic 0: -0.5V min, 0.8V max; 
Logic 1: 2.0V min, 5.5V max 
+1pA max 

Logic 0: 0O.O0V min, 0.4V max; 
Logic 1: 2.4V min, 3.3V max 
Logic 0: 12mA max; 

Logic 1: -8mA max 

1OpF max 








24-bit down counter 

















10MHz, 1MHz, or external signal 
16-bit down counter 

10MHz, 100KHz, or external signal 
+5VDC +5% 

0O.7A - 1.1A typical 

-40 to +850C 

5% to 95% noncondensing 


circuit 





A block diagram of the data acquisition 


can be found in Figure 5. 
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DATA ACQUISITION BLOCK DIAGRAM 


DATA ACQUISITION 
WO HEADER 


15 ANALOG 
INPUTS 


4 ANALL06 
OUTPUTS 


EXTERNAL 
TRIGGER 


cTRO 





Figure 5. Data Acquisition Block Diagram [From Ref. 5]. 


The data acquisition circuit communicates with the 





CPU over the PC104 bus. All control and communication to 
the circuit is performed through register read and writes, 
as the I/O is mapped to registers. All of the registers are 
an offset of the base address of the circuit. In the case 
of this project the base address is 0x280. I/0 time is more 
dependent on the hardware of the circuit than the connection 


between the circuit and the CPU. Communications with the 








DIO port are very fast because there is no extra conversion 


circuitry needed for the output. The only ports that will 
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be used in this project are the digital input/output ports 
A, B, and C. The encoders will be attached to and driven by 


these lines. 


Cc. MICROSTRAIN SENSOR 


dM Background Information 


The MicroStrain sensor used in this project is the 3DM- 


GX1 Microminiature Sensor created by MicroStrain, Inc. in 








Williston, Vermont. [8] The sensor is a three degrees of 
freedom orientation sensor. It has a tri-axial angular rate 
sensor or rate gyro, three orthogonal magnetometers, three 


orthogonal accelerometers, and a temperature sensor. There 





is also a 16-bit analog to digital converter and an onboard 
microcontroller. [9] This sensor is capable of outputting 
orientation in both static and dynamic applications. The 
dynamic accuracy is considerably less than the static 
accuracy, aS can be seen in the next section. A photo of 


the sensor can be found in Figure 6. 
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Figure 6. MicroStrain 3DM-GX1 Sensor. 


The sensor is capable of RS-232 and RS-485 serial 
output. It is able to output raw data at a rate of 
350Hz. [9] It also has the ability to first convert the raw 
data into more useful and recognizable forms such as Euler 
angles, matrix and quaternion before output. Drift in the 
sensor’s data needs to be continually correct due to the 
error and drift of the gyro sensors. The error correction 
is calculated based on measurements from the accelerometers 
and the magnetometers. These two sets of sensors are more 
accurate under a static application and this characteristic 


is used to calculate the correction. [9] 
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2. Specifications 


The following table is the specification table supplied 


by the MicroStrain company. 
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Specifications 


Orientation range 360° all axes (orientation matrix, quaternion) 
(pitch, roll, yaw) + 90°, + 180°,+ 180° (Euler angles) 


Sensor range gyros: + 300°/sec FS 
accelerometers: +5 g FS 
magnetometers: + 1.2 Gauss FS 


Accelerometer nonlinearity 0.2% 
Accelerometer bias stability* 0.010 g 
Gyro nonlinearity 0.2% 

Gyro bias stability* 0.7°/sec 
Magnetometer nonlinearity 0.4% 
Magnetometer bias stability* 0.010 Gauss 


Accuracy + 0.5° typical for static test conditions 
+ 2.0° typical for dynamic (cyclic) test conditions 
& for arbitrary orientation angles 


Output modes matrix, quaternion, Euler angles, & nine scaled 
sensors with temperature 

Digital outputs serial RS-232 & RS-485 optional with software 
programming 

Analog output option 4 channel, 0-5 volts full scale programmable 
analog outputs 

Digital output rates 100 Hz for Euler, Matrix, Quaternion 
350 Hz for nine orthogonal sensors only 


Serial data rate 19.2/38.4/115.2 kbaud, software programmable 


Supply voltage 5.2 VDC minimum, 12 VDC maximum 


Connectors one keyed LEMO, two for RS-485 option 


Operating temp. -40 to +70°C with enclosure 
-40 to +85°C without enclosure 


Enclosure (w/tabs) 64mm x 90 mm x 25 mm 


Weight (grams) 75 grams with enclosure, 30 grams without 
enclosure 





Shock limit 1000 g (unpowered), 500g (powered) 
Table l. MicroStrain 3DM-GX1 Specifications [From Ref. 
9]. 
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One of the main specifications that is very important 
to this project is the static and dynamic accuracy, which is 
seen in Table 1. The table indicates the static accuracy is 
+0.5° and the dynamic accuracy is +2.0°. This is a 
considerable difference. One of the main purposes of this 
project is to test this dynamic accuracy. If the sensor is 
moving quickly, such as in a human motion tracking 
application, the dynamic accuracy has a large impact. A 
larger uncertainty range will not allow accurate tracking 


and execution of a control routine. [9] 


The sensor range in the table is an acceptable range. 
In a human limb motion tracking application 300° per second 


is more than enough range to capture the normal motion of a 





limb. In this project, the pendulum designed and created as 


part of the apparatus will not be traveling faster than this 





sensor range. It will also not be experiencing any motion 





that will create more than +5G’s of force. [9] 


3. Communications 


This MicroStrain sensor will be using the RS-232 serial 
communications standard for communications with the target 
PC104. The default communications protocol is RS-232 with 
38.4kbps, no parity, one stop bit, and eight data bits, as 


seen in Table 2. 


nchronous Character Format 
19.2K / 38.4K (default) / 115.2K 


None 


8 
1 





Table 2. 3dM-GX1 Default RS-232 Format [From Ref. 10]. 
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There are two basic modes of communications with the 
sensor, polled command mode and continuous mode. Continuous 


mode is where th sensor sends out th requested data 











continuously after the request by the host. A new data pack 
is transmitted by the sensor after every calculation. 


Calculations are continuously performed allowing the sensor 











to output the data at its maximum rate. The stream of data 
will have no gaps because the transmission and calculation 
is performed at a set rate by the microcontroller. The host 


computer must be able to receive and process data at this 





rate or faster because if the host computer is not able to 








keep up with the data rate then there will be data packets 











that are dropped. If data packets are dropped the process 














that is relying on the data from the sensor will not execute 
correctly. The user is able to exit this mode of operation 


by issuing a stop command. [10] 


The second mode of communication between the host and 





the sensor is polled mode. This is the default mode the 





sensor is started in. It is possible to change this setting 











by writing to the EEPROM onboard the sensor. Polled mode is 
more interactive with the user. In this mode the host must 


send commands to the sensor to request data. The sensor 





will then send the data back to the host. This method has 
limited accuracy. When the host issues the request for 
data, the packet that is sent back is the packet that is 


being calculated when the request is received by the sensor. 








This means there is a window of uncertainty that spans the 





calculation cycle time, which is 13.107ms for the current 





configuration of the sensor.[11] This window of uncertainty 


is relatively large with respect to the acquisition time of 





the encoder. To get the most accurate time the exact 
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calculation time must be known or the time between data 














calculation start and th ncoder reading be minimized. 











While the polled method could allow encoder reading to be 





taken at the exact time the data calculation cycle starts 








there is no way to guarantee or control this. The 
continuous method does not make it possible to record 
encoder position at exactly the data calculation start time 


of the MicroStrain sensor but the time between the first 











data bit output of the sensor and the calculation start time 
is known and can be compensated for. This enables the 
possibility to match encoder position with MicroStrain 


position based on a time shift of the encoder data. [10] 


A third mode of communication is also possible. It is 











polling while in continuous mode. While the MicroStrain 





sensor is in continuous mode it is possible to also poll the 





sensor for a different set of data. This may increase the 


calculation time required depending on the data that was 





requested. The first set of data that is sent back from the 


sensor to the host is the continuous mode data. The polling 











mode data requested then follows. The host must be able to 


distinguish between the two data packets. 


4. Acquiring Data - Gyro Stabilized Euler Angles 


Acquiring data is performed in two steps. The first 
step is the host must issue a command. The sensor will then 


return the corresponding data. The host may have to issue 





more than one command to achieve desired results. Once the 
sensor is powered up it will automatically start all raw 
data calculations and continue these calculations until 
power is lost. The default mode is polling mode. In this 


case only the command byte must be sent to the sensor. This 
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tells the sensor which set of data is requested. The entire 
list of possible commands is seen in Table 3. When the 


sensor finishes the calculation it is performing, assuming 





it receives a command, it will return the data in a form 


specific to the requested data. This is explained later in 





this section. The MicroStrain sensor is capable of storing 
up to 15 commands in its buffer. They will be output in 


order. [10] 
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Command Set Summary 


Null Command (not implemented) 

Send Raw Sensor Bits 

Send Gyro-Stabilized Vectors 

Send Instantaneous Vectors 

Send Instantaneous Quaternion 

Send Gyro-Stabilized Quaternion 
Capture Gyro Bias 

Send Temperature 

Read EEPROM Value 

Write EEPROM Value 

Send Instantaneous Orientation Matrix 
Send Gyro-Stabilized Orientation Matrix 
Send Gyro-Stabilized Quaternion & Vectors 
Send Instantaneous Euler Angles 

Send Gyro-Stabilized Euler Angles 

Tare Coordinate System 

Set Continuous Mode 

Remove Tare 

Send Gyro-Stabilized Quaternion & Instantaneous Vectors 
Write System Gains 

Read System Gains 

Self Test 

Read EEPROM Value with Checksum 
Write EEPROM Value with Checksum 
Send Gyro-Stabilized Euler Angles & Accel & Rate Vector 
Initialize Hard Iron Field Calibration 
Collect Hard Iron Field Calibration Data 
Compute Hard Iron Field Calibration 
Send Firmware Version Number 

Send Device Serial Number 

Default 





Table 3. Command Set Summary for MicroStrain 3DM-GX1 
[From Ref. 10]. 


To enter continuous mode the host must issue the “Set 
Continuous Mode” command, 0x10, followed by the desired data 
command, from Table 3. The sensor will respond by sending 
the desired data back to the user at a constant rate, 


depending on the setup of the sensor. This will continue 
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until the sensor is reset or the stop command is issued. 
The stop command is similar to the command to enter 


continuous mode. The host must first issue the “Set 





Continuous Mode” command followed by the “Null Command”, 


Ox00. This will cause the sensor to stop sending data out 





continuously. Continuous mode can be re-entered at any time 


if desired. 


The command that is used in this project is Ox0E “Send 
Gyro-Stabilized Euler Angles.” This command gives the roll, 
pitch, and yaw of the sensor with respect to the fixed earth 
orientation system. The angles are according to the ZYX or 
aircraft coordinate system[10]. The format of the returned 


data is seen in Table 4. 


Send Gyro-Stabilized Euler Angles 


Function: The 3DM-GX1™ will transmit the gyro-stabilized Euler 
Angles 


Table 4. Gyro-Stabilized Euler Angles Date Output 
Format [From Ref. 10] 





The RS-232 receiver must be able to receive and process 


this data fast enough so that no data is lost. The sensor 
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will continue to send data regardless of whether or not the 


receiver is receiving the data. The data in roll, pitch, 





and yaw is sent in a raw binary format. The roll and yaw 
have possible values ranging between -32768 to 32767, 
corresponding to -180° to 180°. The pitch has a range of 
-16384 to 16343, corresponding to -90° to 90°. These raw 





16-bit numbers must be reformatted by a scaling them by 





360/65536 to obtain the correct angle in degrees. [10] 


The last four bytes of data sent is very important for 
error checking. This helps to ensure all data arrived and 
is valid. The “TimerTicks” is the word of data that holds 


the value of sensor clock ticks recorded at the beginning of 














every calculation cycle. “TimerTicks” is a 16-bit number so 
when it reaches 65535 it will rollover to 0 on the next 
clock tick. “Checksum” is the reference number for correct 
data. The host must add all preceding bytes of data 
received together. If this number is equal to the 
“Checksum” then the data received is correct. If the 





numbers are different, the data is invalid for a list of 





possible reasons: interference, incorrect data set, etc. In 





the case of command Ox0E, “Send Gyro-Stabilized Euler 
Angles”, the “Checksum” would be compared to 


OxOEt+rollt+tpitchtyawtTimerTicks. [10] 


5. Calculation Cycle Information 


The amount of time between clock ticks is programmable. 


The default value is 6.5536msec. [11] This the value used 





for this project. The clock will always cycle at this 


speed. Not all the calculations will be completed in one 





cycle of the clock. It may take as many as 10 clock cycles 





to compute the output depending on the desired output and 
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the clock speed, as seen in Table 5. For this project, at 
6.5536 msec per tick, it requires 2 complete timer ticks for 
the OxOE command calculation to complete. As seen, it is 
standard for all the command calculation timer ticks at 
6.5536 msec to be two ticks. The time could be changed to 
10 msec, which would clearly speed up the sample rate, but 
if all the sensors are defaulted to 6.5536, it makes more 
sense to test at default rather than reset the internal 


circuitry of every sensor this apparatus will test.[11] 


Timer Ticks required to complete Calculation Cycle 


6.5536| 10.0| 9.0] 80] 7.0| 60] 50| 40] 3.0{ 2.0] 1.0 
| 


Cmd 





roar 1 at 2 2 2 tt 


Table 5. 3DM-GX1 Clock Cycles per Calculation Type 
[From Ref. 11] 


In the above table, the “T” means that particular 
command under that associated time does not have a 
guaranteed number of ticks. This is because the timing is 
so close to the edge of a timer tick that it can be assumed 


it transitions for some time on either side of a timer tick. 





Some cycles may take only 1 tick while at other times it may 
take 2 ticks. The red and blue cells are highlighted for 
purposes of the documentation it was drawn from and they 


have no purpose here. 
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Timer Ticks x Timer Tick Interval = Total Time to Complete Calculation Cycle 


foae [ear ot 
I 
is [41210] 121 


| 6 {412 

| 6] 14] 12] 10] 12) 

| te] 16] 14] 12] 10] 1 10 
poxoD | 73.107 








13.107 
Table 6. 3DM-GX1 Total Calculation Time per Type [From 
Ref. 11] 


The above table shows the total time for each 


calculation cycle in milliseconds. To arrive at these 





numbers the clock cycle time is multiplied by the timer 





ticks required from Table 5. The “T”, red, and blue cells 
are the same as in Table 5. The green cells are the fastest 
calculation cycle time for each command. Again, this was 


not used because all the default values were used to 








standardize the calculations from command to command and 


sensor to sensor. The above table shows the calculation 
cycle time for the Ox0E command is 13.107 msec. This means 
every 13.107msec a new data point can be read. The sensor 


outputs data at 76.295 Hz.[11] 


D. ENCODERS 


There were two encoders used in this project. One was 
a 10-bit absolute encoder created by Computer Optical 
Products, Inc. The other encoder was a 16-bit absolute 


created by Gurley Precision Instruments. 
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1. 10-Bit Encoder 


The first encoder that was used in the project was the 
10-bit absolute encoder, CP-350-10GC, manufactured by 
Computer Optical Products, Inc. The output is standard +5V 
TIE. 50kHz is the maximum data output rate. All data is 





output in a 10-bit parallel, grey code form. This requires 
a conversion from the grey code to binary code. Once the 
output is in binary code it can then be converted to an 


angular degree. [12] 


There are a number of different methods that can be 


used to convert grey code to binary. The following general 





formula for the conversion is from Ref. 13: 
Bh = GatBa + 1 + Ga Bat 


In this project, a short code routine was used for the 


conversion. The pseudo code can be seen in Figure 7. 


BEGIN: set BO through B11 = 1 


B11=G!11 

IFB11=G10 THEN B10=0 
IF B10 = G9 THEN B9=0 

IF B9 = G8 THEN B8 =0 

IF B8 = G7 THEN B7 =0 

IF B7 = G6 THEN B6 =0 


IF Bb = G5 THEN B5=0 
IF B5 = G4 THEN B4=0 
IF B4 = G3 THEN B3 =0 
IF B3 = G2 THEN B2 =0 
IF B2 = G1 THEN B1 =0 
IF B1 = GO THEN BO =0 
DONE 





Figure 7. Grey Code to Binary Pseudo Code [From Ref. 
alec gee 
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This code is clearly for a 12 bit application. For the 
purposes of this project the second line “B11=G11” would be 





changed to “B9=G9.” All the lines after the second line 
would follow the pattern. The resulting binary number will 
be able to be converted Lo degrees by: 


DEGREES=BINARYNUMBER* 3360/1024. 
2. 16-Bit Absolute Encoder 


The 16-bit absolute encoder was created by Gurley 
Precision Instruments located in Troy, NY.[14] A photo can 


be found in Figure 8. 





Figure 8. A58 16-Bit Encoder and Attachment. 
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It is a model A58 encoder. The part number is very 


important because ane describes th ncoder’s 








characteristics. It is A58S1L6MBTTO5SAT39004EN. The 


following is the breakdown of the part number’ and 











characteristics[14]: 


A58- Model number. It is specific to the Gurley 
Company. 

s- Shaft type. S indicates a solid shaft. 

16- Resolution. It has 16-bit resolution. The 
absolute resolution is 5.493x10° degrees per 











count. 
M- Output Format. This encoder uses a multiplexed 
parallel output. 8-bits at a time are output, 








starting with the least significant 8-bits first. 





There are more specific output details later in 
this section. Serial output could have been 


selected but the DIO can read parallel much faster 





and more easily than serial. It only takes 2 read 








cycles to acquire all information with parallel 





communications while it would take 16 read cycles 


to get all the information with serial 
communication. 
B- Output Code. The output code of this encoder is 


binary. It can also be grey code like the 10-bit 





encoder. This is not practical for this project 





because the DIO ports are read and treated as a 


binary number. If grey code were used, a more 








time intensive program would have to be written to 

















tak the grey code and convert it into the 
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TT- 


05- 


39> 


corresponding binary number. This is an extra 





step that is eliminated if the encoder outputs the 


binary number to start. 


Output Device. Since this system is using digital 





input as the interface with the encoder it makes 





most sense to use a TTL signal coming from 





encoder. The other signal options would require 
extra circuitry to be compatible with the DIO 


input device. 


Voltage. The digital to analog convert on the 





PC104 is able to output 05.0 volts which can be 








used to drive th ncoder. 


Temperature Range. This system is not intended 
for implementation in hazardous situations so a 
standard temperature range of 0-70 Cc is 


sufficient. 


Base type. A is the only option available for this 
model. It is a combination synchro flange/face 


mount base. 


Cable Exit. The particular setup of this system 





would most easily interface with the encoder if 


the cable exited out the top of the unit (back) of 











the encoder rather than the side. 


Cable Length in inches. A different size could 


have been selected, but 39” is the standard option 





so that is what was selected. 
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Connector. Q@ corresponds to a DA-15P type plug. 
This is a 15-pin male connector. The pin 
assignment and plug diagram can be found later in 


this section. 








O4E- Shaft Diameter. O4E corresponds to a= shaft 
diameter of 1/4". This size was selected becaus 
the 10-bit encoder set up could already accept a 
1/4" diameter shaft. 
N- Special Features. There were no special features 
ordered. 


The overall specifications of the encoder can be found 


in Table 7. The far right column is th ncoder used in 





this project. 
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Model Model Model Model 
A58-12 A58-14 A58-15 A58-16 


Moment of Inertia, in-oz-s’ (g-cm’* 2.5x 10° (17 
[Radial ShaftLoad,Ib(N) CP C“(‘t;*C‘“‘(‘;SC;C(;*S(ONDCOOOOC‘(‘(’SCSN’NCNC‘idC 


Axial Shaft Load, Ib (N 
2 pre-loaded bearings 
le 








[seaing IP; IP65 (686 table on Ouitine Dimensions) | 
SCA 


Recommended Shaft Coupling: Model 








Environmental Specifications 








Storage Temperature, F (C) 0 to 160° (-18 to 71°) 
98 


Relative Humidity, % (non-condensing) 
Electrical Specifications 


Supply Voltage, VDC 


| Maxis0 | 250 | 250 | 250 
a ae a: es 
Output Format: = ae ee ee ee ee eee 











Table 7. A58 16-bit Encoder Specifications [From Ref. 
14). 
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The pin assignment of the encoder can be seen in Table 


Electrical 
Signal 


yellow 
brown 
green 
yellow-white 
blue 
white 
violet 
gray 
white-green 


1 
2 
3 
4 
5 
6 
7 
8 
9 


ak 
So 


— 
— 


=k 
Nh 


yellow-brown 
black 
red 
shield 


ah ah ob 
on & GW 





Table 8. Pin Assignment of Encoder Exit Cable [From 
Ref. 14]. 


Signals DO-D7 are data lines for the position data of 


the encoder. They carry the byte of data available based on 








the requested set. These lines are all output only. DA is 





the signal for Data Available and is active low. This 


Signal is output only and it tells the user when the data on 





the data lines is valid. OE1l and OE2 are both input lines 








and are both active low. These lines indicate to the 
encoder when the user would like which set of data. Only 
one of these two lines should be low at a time. OE1 low 





indicates to the encoder the user would like the least 

Significant byte of data. This is bits 0-7 of the encoder 

position. When OEF2 is low the encoder outputs the most 

Significant byte of data. This is bits 8-15. When both of 
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these outputs are put together the 16 bit position of the 





encoder is realized. The OV signal is the reference or 


ground signal for the encoder. This should be connected to 





the ground of the system. +V is the high voltage input. 








For the particular model used in this project the high 
voltage is +5V. CASE connects to the casement of the 


encoder and is not used in this project. [14] 


The connector plug can be seen in Figure 9. 


Or GO OO: 
OOO Oo ee 


Figure 9. Male plug of the encoder. 





The timing diagram of the encoder unit is very crucial 
in understanding how the encoder unit works as a whole. The 
timing diagram can be seen in Figure 10. The diagram shows 
lines OEF1, OEF2, DA, and DO-D7 with T1=80410ps, T22300ns, 
T32300ns, and T4S200ns. [14] 
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T1 T2 


OE1 


OE2 


DA 


DO 


D5 


D7 











Data available 


Figure 10. Timing Diagram of A58 Encoder [From Ref. 14]. 





These are the steps that must be followed to acquire 


data from the encoder: 


1. OE1, OE2, DA are all high. DO-D7 are usually low, 





but this is not guaranteed. They are in an unknown 
state, Z in the timing diagram. When in this 
unknown state the data available on the lines is not 


valid. 


2. User must take OE1 line low. The falling edge of 


OE1 latches the current position into the on board 
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memory. Every time this line is taken low, the 
encoder always clears the position memory and stores 


the current position. 


. After Tl, DA appears low. The first instance that 





data is available is when DA is low. Tl is not too 
much of a concern in the project beyond being a 


reasonable time. The biggest concern is getting 





both sensors to latch at exactly the same time. The 





data read can occur any amount of time after the 





latch. A reasonable amount of time for Tl would be 
any time less than 100s. This project does not 
require a degree of accuracy in dynamic motion 


faster than 10kHz because the MicroStrain sensor is 





not able to output faster than 350Hz. [11] 


. Once DA appears, the least significant byte may be 
read. DO corresponds to bit 0O and D7 to bit 7 of 


the position. 





. After the read is complete the user must pull OE1 





back to high to signal to the encoder the least 
Significant byte read is complete. After T4 the 


data on the line will not be in any particular 





state. It is bad data and should not be read. T4 


is not a crucial time but is included to indicate 





transition time for the data lines, even if the 








transition is to useless data. 


. After T2 the user must pull OF2 low. This indicates 


to the encoder to place the most significant byte of 





the already latched data on the data lines. 
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7. DA will then transition to low after T4. This 











indicates to the user that the upper byte of the 








position word is available. 


8. The user is then able to repeat the process to latch 








and read another value. If OF2 is transitioned low 
before OF1l is transitioned low, the data available 
will still be the old data. OE2 may be pulled low 
and the upper byte data read any number of times 


without affecting the data. Although, as soon as 








OE1 is pulled low, the data is reset and a new set 


of data will be available. 


If for any reason the V+ input does not have the 


correct voltage and current supplied, the output will not be 











correct. The encoder may appear to be functioning correctly 
at first, but upon further investigation, it will be found 
that the data output is faulty. The vt+ of the encoder 


requires 5V at 250mA[14] and the data acquisition circuit is 





only able to supply 5V at 5mA of current from the DAC. This 
means the encoder must be driven by an outside source, or 


the constant +5v of the data acquisition circuit must be 





used. In this project the constant +5v from the data 


acquisition circuit was used. 





E. THE PENDULUM 


The pendulum is the main source of motion and 
connection between the sensors. The pendulum length is 
supplied by a half-inch wooden dowel rod which is 43 inches 


long. While the dowel rod does contribute more error due to 





torsion than metal would produce, the more important factor 
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is the effect a metal rod would have on the internal 


magnetometers of the MicroStrain sensor. The MicroStrain 





sensor is connected to the wooden shaft by a plastic 
bracket. The combination of the mounting holes and the fact 
that the pendulum can rotate its orientation within the Z 
axis of the shaft allows the sensor to be placed in every 


vertical and upright horizontal orientation possible. The 





ntire assembly can also be repositioned on its side to 
capture horizontal motion of the pendulum ensemble. The 
pendulum connects to the encoders by a clamp on the shaft. 


This ensures a strong secure connection but at the same tim 











it allows the pendulum length to be readjusted. Readjusting 








the pendulum length will also allow the period to be 
altered. Since the MicroStrain sensor is intended to be 
used to capture human motion, having the adjustable period 
allows the pendulum to simulate different limb’s sections 
performing different motions. Photos of the pendulum can be 


found in Figure 11. 


Dil. 





Figure 11. The Pendulum. 
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A. SETUP 


IV. TEST 


This section describes the setup of the system, 


concentrating 


communications. 





on connections and inter-module 





A block diagram of the test system can be 


found in Figure 12. The actual setup can be seen in Figure 


13. 


Figure 12. 











Ethernet 


ISA Bus | Data 
Acquisition 


104 CS) Circuit 





Motion 





Motion 





3DM-GX1 Pendulum 


Block Diagram of Setup of test system. 
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Bi ai. 


= 


Target PC104 Oy é ‘ MicroStrain Sensor 


o 


Data Acquisition Circuit I/0 
Wireless Router (ma Ses 


Figure 13. Actual Experiment Setup. 








1. Ethernet and Associated Setup Procedures 


The main form of communication between the host and the 
target of this system is an Ethernet connection. At 
different points throughout the project the two computers 
were either directly connected or connected through a 
wireless connection. The wireless connection used was the 


IEEE 802.11g. The host was connected directly into a 





wireless router and the target PC104 was connected to a 








wireless receiver. This connection was set up and used 
strictly for demonstration purposes. The connection was 
fast enough that program execution was not impeded. The 


only purpose of the connection between the host and target 
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is for debugging, console out, and sending the compiled 





program to the target for execution. None of the programs 








that were tested used the console out in any important 





application. It was only used as a debug tool so the speed 





would have little impact on program execution. 





For testing and data recording the hard connection 
between the host and the target was used. This consisted of 
a CAT-V crossover cable connection between the Ethernet 
ports of both systems. The connection speed used was 


100Mbps. At this connection speed and under the demands of 





the program, there was little to no disadvantage of running 
under a host/target system rather than running strictly 


under a target only system. 


For the Ethernet connection to be effective and for the 











communications to function properly, there were a few setup 





procedures that needed to be completed. The main 





communications between the two systems occurred because th 





QONX Momentics IDE needed to talk with the program executing 
on the target PC104. For this communication to be possible, 


the PC104 needs a small process to be continuously running 





that establishes this communication link. The program 








called qconn, developed by QNX, is the small process that 





allows this communication. gqconn must be running on the 
target machine for Momentics to be able to send and execute 


compiled programs on the target machine. This process can 





be started at anytime after the OS is fully booted. 





A second process must also be running in the background 








for proper communication between the host and the target. 


The process which allows communication between any two QNX 





based systems is called phrelay. This process allows remote 
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login to occur from the QNX developed program Phindows. 


Phindows is a Windows based remote login program. It allows 





a user to start a totally new session of QNX Photon, the QNX 
OS graphical user interface. The session is hosted on the 
ONX system but is accessed and controlled by the remote 
Windows system. This program is an excellent tool that 


allows the PC104 to function as a very powerful remote 





embedded system. With this program the user is able to 





eliminat Eh need of a monitor or any direct physical 








contact with the PCl104, yet at the same time have the 





capability to control every aspect of the machine. Remot 
file transfer protocol (FTP) communications are also 
necessary. 


FTP allows the fast transfer of files between two 
computer systems. This is necessary for this project 
because the PC104 is not powerful enough to do much visual 
analysis of the recorded data, especially remotely. The 


MATLAB program is also not able to execute on the QNX OS. 





MATLAB is a very powerful data analysis tool that is used in 





this project. MATLAB will execute on a Windows system, thus 





creating the need for a file transfer. The output file that 





is stored on the PC104 that contains all the test data can 
be transferred to a Windows based system by an ftp file 


transfer. 


The common UNIX program inetd gives the OS a way to 





manage most internet type services and processes. For the 


ONX OS to support FTP capabilities, inetd must be a 





currently running process. This allows a user to log into 
the FTP client of the ONX system from a Windows system. The 


command line FTP client on Windows systems is directly 
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compatible with the QNX FTP client and is accessible when 
inetd is running. A second advantage of running this 


program is that phrelay is automatically started when th 








inetd process is started. When the inetd line is included 





in the /etc/re.d/re.sysinint system initialization file, the 








two processes will automatically start on operating system 
startup, allowing instant and automatic FTP and _ remote 


access client access from a remote system. The inetd line 





is included in this file directly following the system boot 


indicator program discussed previously. 


2 RS-232 


Serial Communication is the main form of communication 





between the MicroStrain sensor and the target PC104. 
Communication is performed following the RS-232 standard. 
The baud rate is 38.4Kbaud with 8 bits, 1 stop bit, and no 


parity. All communication with the sensor is directed 





through COM1 of the PC104, I/O address O0x3F8-0x3FF. The 
PC104 has a standard 16550 type UART on the micro CPU chip. 








The UART has a 16-byte first in first out buffer. The UART 


is set to IRQ 4. This means all interrupts associated with 
the UART will appear on interrupt request line 4. The 
specific setup of the COM1l port is discussed in the 





Acquisition Program section. 
32 Digital Input/Output 


Both encoders communicate with the PC104 through the 
digital input/output (DIO) ports of the data acquisition 
circuit. All the data is recorded as input to the DIO. The 


16-bit encoder actually uses some digital outputs to drive 





the output enable lines. The signals are all TTL. 5V 
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corresponds to logic 1 and OV is logic 0. When the DIO 
ports are read, each port gives an 8-bit number representing 


the status of the port. 


The 10-bit encoder has no control input so no digital 
output from the PC104 is necessary. The encoder is driven 


by the analog to digital conversion output “Vout0” on the 








data acquisition circuit, pin 29. The program outputs a 
constant 5V on this pin. This voltage drives the LED inside 
the encoder. The rest of the pin to pin connections can be 


seen in table 9. 


Data Acquisition 
Circuit 





OLOJO!O 





O 


IO A4 5 q#— 11 G4 
TO A5 6 q— 6 G5 


D 


























Vout 

Agro 
Table 9. 10-Bit Encoder Pin-Pin Connection Table. 
DIO ports A and B must be set as input. Port A when 





read will give the complete least significant grey code byte 
of data. Only the first two bits of port B must be read. 
If all the bits are read then only the first two must be 








used. These are the two most significant bits of the grey 
code position of the encoder. The two ground pins must be 
connected together to establish a common ground. If this is 
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not connected then the DIO may not read the bits correctly 


and the LED in the encoder will not light. 


The 16-bit encoder is connected in a slightly different 


configuration. The output enable control lines of this 








ncoder require a 5V TTL signal. Originally, lines OF1 and 





OBR2 were connected to an analog output of the data 





acquisition circuit. The effect of this is discussed in the 
Results section. The pin connection can be seen in table 
10. 


Data Acquisition 
Circuit 





Description Pin Pin Description 



































Table 10. 16-Bit Encoder Pin-Pin Connection Table. 





Port A and B must be set for input. Th ntire byte of 
data is input through port A. Port B must also be set for 
input so “data acknowledge” can be read from the encoder. 


It is important for the computer to be able to read the DA 





Signal. Port C must be set for output. Outputting OEF1 and 


OE2 on a TTL line is crucial to get correct and accurate 





data. The encoder could be driven by a DAC of the data 


acquisition circuit at a quick glance, but in reality it is 
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not possible. The DAC does not supply enough current to run 


the encoder without a buffer to supply the extra current. 





When the encoder power is connected to the +5V of the data 





acquisition circuit enough power is supplied to drive the 


encoder. 


B. ACQUISITION PROGRAM FOR THE 16-BIT ENCODER 


The acquisition program described here will be the 


program associated with the 16-bit encoder. The 10-bit 








encoder code is similar but the results and methods were not 
as accurate as with the following method used with the 16- 
bit encoder. The 10-bit encoder program will be described 
in a later section. It only describes the differences 


between the 10-bit encoder program and the following one. 


The flow of the program is one of the most crucial 
aspects of the project. Incorrect programming could lead to 
inaccurate or incorrect data. The program is split into two 
main sections, the main routine and the interrupt service 


routine. The data acquisition board initialization, serial 





port setup and initialization, file output, and all other 








initializations will be described under the main function 





section while the DIO and serial port reading will be 





explained under the interrupt service routine section. 





Sections of code will be described in the following 





sections, although the entire program can be found in 


Appendix A. 


The file control.wse is included in the beginning of 
the program. The file is a header file with function 
definitions that were used in the program. The file also 


contains all the header file inclusions that were used in 
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the project. This slimmed down the program by writing all 
the include statements in a separate file. The control.wse 
file was added to for this project. The base variable is 
the base address of the data acquisition board and in this 


application it is 0Ox280. All registers of the data 








acquisition board are an offset of this address. 


‘i Main Function 


The main function is where the program first starts 





execution. The first section of the main routine consists 


of mostly initialization routines. There are many 








initializations that must be completed for proper operation 








of the system. The first part of the code is seen here: 
oe BoardInit (); 


All code here and in the following section, unless 


otherwise noted, is taken from Appendix A. This is the 
first few lines of the main function. BoardInit() is a 
function that is found in control.wse. The code for this 
function is seen here: 





46 int BoardInit (void) 





47 { 

48 int privity_err; 

49 privity_err=ThreadCtl( _NTO_TCTL_IO, NULL ); // thread gets 

root permission at access hardware 

50 if (privity_err==-1) 

poy { 

52 cout<<"can't get root permission"; 

5S. return -1; 

54 } 

55 out8 (base + 0, 0x40); //reset the board, except the DAC output 

56 return 1; 

SF *} 

This code is taken from Appendix B. Line 49 is the 

most important line here. The Threadctl function is a QNX 
Neutrino specific command. It gives root permission for the 


thread to access all I/O functionality. With this line of 
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code, the program will not be allowed to access any I/0 





functionality. Lines 50-54 simply return to the console an 
error message if root permission is not attainable. Line 55 
is a data acquisition circuit specific register write. This 


line writes a 0x40 to the base address which causes the 
entire board to be reset. All DIO becomes input, all 
counters/timers are stopped, and all registers will be set 


to 0. The digital to analog circuitry is the only part of 





the board that is not affected. Once the board is reset the 


function will return al if successful. 


The next set of lines in the main function are seen 


here: 
53 out8(base + 11, OxFE); //set all DIOA DIOB to input DIOClow 
Output 
54 SetOEBits(1,1);//OE1 OE2 high 





Line 53 sets DIO port A and B to input, sets bits 1 and 
4, and the lower nibble of port C to output, set bit 0. 
Bits 2,3,5,6,7 do not matter so they are set to 1, giving a 
value of OxFE to be written to the register. When the DIO 


line control is changed from input to output for any of the 





ports, the respective ports are all pulled low. If the 








encoder is attached to the circuit and is currently on, the 
encoder will actually take a reading during this time. 


However, the flow of operations in this program do not allow 





this reading to affect any of the other readings. There 
must be careful attention given to this or the encoder may 
not produce the correct reading that is requested. The code 


for this function is seen here: 


152 void SetOEBits(int OE1, int OE2) 
































L532: 4 

154 out8 (baset+10, (OH1 + 2*OE2)); //Pulls OF bits in either 
direction, 1l-high, 2-low, OE1 must be on pin 17, OE2 pin 18 

155. } 
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This function will receive two integers that must be 
either a 1 or a O for this function to work correctly. Al 
represents high and a 0 low. When the function is used, the 


values sent correspond to what the program requests the 





status of bits 0 and 1 of the DIO port C output be set to. 
Bit 0 is the first parameter and bit 1 is the second 


parameter. In the function, the only code executed is an 





output to register base + 10. This register is the DIO port 





C status register. Writing either a 0,1,2, or 3, as in this 


case, will change the bits 1 and 0 to represent the binary 





value of the number sent. This means that the other bits 


are all set to 0. In the case of this program there is no 





problem because none of the bits excluding 0 and 1 are used. 


If these bits are to be used in a different application, 





this code will have to be modified to first read the status 
of port C, change only bits 0 and 1, and then send the value 
back. In this program this code was not included because 
this function is executed in the interrupt service routine, 
ISR, as well as the main function. The idea is to minimize 


code execution in the ISR, therefore the extra code was 





decidedly excluded. 


The next set of code is seen here: 


56 SerialBit=0; 

sy DataIndex=0; 

58 DataSetSize=1000; 
59 

60 SerComInit (); 


Lines 56-58 initialize various variables for the 
program. This particular set of variables is actually 


global variables because they are used in both the ISR and 








the main function. They are initialized here to ensure 
proper operation. SerialBit is the variable that is used to 


indicate where in the receiving serial data packet the ISR 
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is. This helps to ensure that only an 11 bit package is 





taken off the UART buffer at a time. More will be discussed 





on this in the ISR section. DataIndex is the current data 
set that is being recorded. This is used in the index that 
will indicate how many and where the data is currently being 


stored in the encoder data and MicroStrain sensor data 





arrays. DataSetSize is the desired number of data points to 
record. For this project, 1000 data points are enough data 
to allow a thorough analysis. Line 60 is the function that 


sets up and initializes the UART and RS-232 operation. Seen 
here is the actual function code: 


92 void SerComInit (void) 


eae 
94 out8(sbase + 4, 0x09); //MCR data terminal ready 
95 out8(sbase + 3, 0x83); //enable latch for baud rate set 
96 out8(sbase + 0, 0x03); //lower baud divisor 
97 out8(sbase + 1, 0x00); //upper baud divisor 
98 out8(sbase + 3, 0x03); //disable latch, 1,N,8 
99 out8(sbase + 2, 0x07); //set FIOF to 1 character 
100 out8(sbase + 1, 0x15); //enable recv interrupt 
101 } 





A #define statement that establishes sbase is 
established at the beginning of the program code file. This 
is the base address of the UART. The address for the target 





PC104 is Ox3F8. All registers used for setup and 


initialization are offsets of this base address. There are 





many steps that are required to ensure proper operation of 
the UART and proper interface with the MicroStrain sensor. 
The modem control register is sbase + 4. This register 
control is used for handshake procedures. In the case of 


this program, there is no handshake needed because the 





sensor does not require any, so the port is set as follows: 


Bit 0: 1 - Data terminal is ready for data 





Bit 1: 0 - No request to send data 
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Bit 3: 1 
Bit 4: 0 
Bit 5: 0 
Bit 6: 0 
Bat. “Fs "Q 
The next 


Option 1, not needed 


Option 2, needed to enable proper interrupt 


operation on some PC based systems. 
No loopback, normal operation 
Not used 


Not used 











Not used[15] 


register that requires setup is sbase + 3. 





This register is the line control register and is set up as 


follows: 
Bact. Oe C1. 
Bit 1: 1 
Bit 2: 0 
Bit 3: 0 


Word length for traffic is set to either 6 


or 8. Bit 1 specifies which. 


Word length of 7 or 8. In conjunction with 
bit O the word length will be 8. This is 
needed because the MicroStrain sensor 


outputs 8 bit words. 


Number of stop bits. The MicroStrain sensor 
outputs 1 stop bit. This bit must be set 
to receive and send 1 stop bit. Since the 


word length is set to 8 bits, a 0 in this 





bit will indicate 1 stop bit. 





The MicroStrain sensor does not include any 





parity in its formatting. Setting this bit 


to O indicates no parity. 
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Bit 








Bit 


4; 


0 





-— Not needed because parity is set to 0. This 


bit would otherwise indicate even or odd 


parity. 


Not needed because parity is 0. 





A 0 does not require a break condition. A 


break is not need for this application. 


This gives access to the baud rate counter 
latch. If the baud rate is to be set, this 


bit must be set to l. The baud rate is 





actually stored in a register that is 
mapped to two different locations. The 


transmit/receive buffer and the baud rate 





divisor least significant byte are both 


mapped to register offset O while interrupt 





enable and the divisor most significant 
byte are both mapped to register offset 1. 


When this bit is set, the divisor registers 





are the registers that are accessible while 


the others are not, until this bit is set 





back to 0. It is crucial for proper 





operation that this bit is set back to 0 


before the UART is enabled for 





operation. [15] 


Since the UART is now mapped to set the baud rate it 


at 1.8432MHz. 


would make most sense to set the baud rate. Lines 96 and 97 
set the baud rate. The UART has a clock that is set to run 


To get the desired clock rate a divisor must 





be used to divide the clock rate to the desired baud rate. 
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In this case a baud rate of 38.4kbaud is needed. Under the 





16550 standard of UART the 1.8432MHz clock is naturally 
divided by 16 before the divisor is applied. This means the 
clock is 115.2Kbaud if the divisor is 1. A divisor of 3 








will result in a baud rate of 38.4Kbaud. This value is 








entered into the least significant byte of the baud rate 
divisor, sbase + 0, line 96 of the code. The most 
Significant byte of divisor is 0, which is set in line 97. 


Immediately following this instruction, the line control 








register, sbase + 3, is again set in line 98. This resets 
only bit 7 of the register. It is very important to ensure 
all other bits are unaltered as this would change the parity 





and the word format. Line 98 writes 0x03 to the register. 





The only differenc between this instruction and the 





instruction previously written in line 95 is bit 7 is 








changed to a zero. This will allow the UART to remap the 0 





and 1 register offsets back to the transmit/receive buffer 








and the interrupt enable register. 





Lines 99 and 100 set up the first in first out buffer 





control register and the interrupt enable register. Since 





the MicroStrain sensor sends data back at the end of its 
calculation cycle in a packet of data that has a size that 
varies with the type of data, the interrupt will need to be 


set when it receives as little as 1 character. If the 








interrupt is called for every character, it does not matter 





the size of the data packet being sent by the sensor because 








the ISR will be able to take all the characters sent one at 
a time. The ISR will have to be told how large of a data 
packet to expect to ensure each character is placed within 


the correct data packet. 
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It is very important to synchroniz th ncoder 
measurement and the MicroStrain sensor measurement as 
accurately as possible. One way for the sensor to 


communicate with the encoder is through the interrupt 





service routine. If the encoder is read on the last data 





character sent by the sensor, it will be possible to 
synchronize the two measurements as accurately as possible. 
The data packet sent by the sensor in this project is 11 
characters long. The first in first out character buffer of 
the UART can cause an interrupt on 1,4,8, or 14. The only 


value that works for the application in this project is the 








character setting. This setting, in conjunction with the 





ISR knowing which character of the data packet it is 


currently receiving, allows the ISR to know exactly when to 





take an encoder reading, thus minimizing the time difference 


between the ncoder reading and the MicroStrain sensor 





reading. 





The first in first out (FIFO) buffer control register 




















is initialized in line 99 of the code. The register offset 
is 1. The bits are set as follows: 

Bit 0: 1 - Enable transmit/receive FIFO. 

Bit 1: 1 - Clear the contents of the receive FIFO. 


After this is called the value of this bit 


will be automatically reset to 0. 


Bit 2: 1 - Clear the contents of the receive FIFO. 





After this is called the value of this bit 


will be automatically reset to 0. 


Bit 3: 0 —- No change in the transmit/receive mode. The 





difference in mode only deals with how the 
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Bit 4 
Bit 5 
Bit 6 
Bit 7: 


In order 


RXRDY and the TXRDY pins function. These 
pins are not used in this project so this 


bit will remain unchanged. 


Not used. 





Not used. 


Trigger level for the receive FIFO 





interrupt. A 0 here and in bit 7 will 


indicate the level 1. 


In conjunction with bit 6 being a 0, the 





FIFO will cause an interrupt every time 





there is 1 character in the buffer. [15] 


for the interrupts to actually occur the 





interrupt enabl 


register must be set. Line 100 contains 





the instruction 





that will perform this task. The register 





offset of 1 is set with the following byte: 


Bit 0: 
Bit 1: 
Bite 2: 


1 








Enable the receiver ready interrupt. This 





interrupt will occur if the FIFO has a 





character that is ready to be received. 


- Disable the transmitter empty interrupt. 


Transmit interrupts are not useful in this 





application 


- Receiver line status register change 
interrupt. This interrupt will occur for 
various reasons. Data available, parity 


error, framing error, and various other 


errors will cause this interrupt. If this 





interrupt occurs the line status register, 
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offset 5, will have to be polled to 





determine the cause of the interrupt. This 








interrupt is never actually used in the 





code for the project, but this interrupt 
could be used. The ISR will discard any 


information that is not correct based on 





what data is expected. 


Bit 3: 0 - Modem status register interrupt. This 


interrupt is not needed since the only 





program that will be altering the UART is 


this program. 


Bit 4: 1 - Sleep mode for a 16750 UART only. This does 


nothing in this project. 
Bit 5: 0 - Not used. 


Bit 6: 0 - Not used. 








Bide te tO Not used. (.15)] 


Writing the previous byte to sbase + 1 initializes and 
starts the indicated interrupts. Any information received 
by the UART will now cause an interrupt. The next step of 


the program is to nsure the MicroStrain sensor is not 





outputting any data and it is not in continuous mode before 





the interrupt service routine is enabled. If it were in 





continuous mode, the interrupts would start as soon as the 


interrupt service routine is attached to the interrupt of 





the UART. To maintain full control over the interrupts the 











sensor must not be sending data back until the program is 
ready to receive the data. Line 61 of the code, under the 
main function, is the function that will do this: 
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61 StopCONTmode (); 
The definition of this function is after the main 
function and seen here: 


123 void StopCONTmode (void) 


124 { 

125 out8(sbase + 0, 0x10); //Command Command 
126 out8(sbase + 0, 0x00); //Null Command 
127 out8(sbase + 0, 0x00); //Null Command 
128 } 


To output characters on the serial line, COM1 serial 








port, the characters must be written to the transmit FIFO 
buffer. This is accomplished by writing to the base 
register of the UART, address sbase. When the character is 
read it is then sent out by the UART. Line 125 sends the 
“Set Continuous Mode” command over the RS-232 line. This is 


then followed by two null commands in line 126 and 127. 








This sequence of characters, when received by the sensor, 
indicates that the sensor is to stop continuous mode and 


listen for a further command, either a polling command or 





another command to reenter continuous mode. Polling and 





continuous modes are explained in more detail in the 


MicroStrain sensor section of this paper. 


Continuing in the main function, the next command is 


the Interrupt initialigation function: 





62 ISR4Init (); 





This function initializes and attaches the interrupt 


service routine to the interrupt of the UART. This 
interrupt is set to occur on IRQ line 4. This is set in the 
BIOS when the target PC104 first starts to boot. The 





following code is from the control.wse file: 


361 /* Initialize IRQ 4 handler*/ 
362 int TSR4Init (void) 








363 { 

364 isr4handid=InterruptAttach (4,isr4_handler, NULL, 0, 
NTO_INTR_FLAGS_TRK_MSK); 

365 } 
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ISR4Init() initializes the interrupt service routine 
for IRQ 4. Line 364 attaches the interrupt handler 
isr4_handler to IRQ 4. Once the handler is attached the 
returned value is the ID of the ISR handler. This value is 
only used to mask and unmask the interrupt. isr4handid is a 
global variable that is declared at the beginning of 


control.wse. The ISR handler code follows; it also is 





contained in control.wse: 


354 /*IRQ 4 Handler*/ 
355 const struct sigevent* isr4 handler(void *arg, int intr) 
356.4 





357 isr4 routine(); //ISR routine 
358 InterruptUnmask (4,isr4handid); //Enable IRQ 4 
359. } 


The QNX operating system uses signals to communicate 











interrupts. This is why the type definition of the 
interrupt handler is sigevent. The first line of the 
handler is the interrupt service routine. The code for the 


ISR is found in the main code, just above the main function. 





Every time an interrupt occurs on IRQ 4, this ISR handler is 


executed, which in turn executes the ISR. The last line of 





the interrupt handler, line 358, is the unmask command. 
This command tells the operating system to unmask all 


interrupts on IRQ 4 that are attached to the interrupt 





handler with the id in isr4handid. This is the final 





instruction that actually stats the action of the interrupts 
to be handled by the defined ISR. After this command all 


interrupts on IRQ 4 will cause the ISR to execute. 


After all the initializations are complete, the program 





is ready to start collecting data. This is started in line 


64 of the code: 


64 SendInstantEulerAngleCONT (); 
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The definition of this function can be found later in 


the code file, and seen here: 





116 void SendInstantEulerAngleCONT (void) 


LI? £ 

118 out8(sbase + 0, 0x10); //Command command 

179 out8(sbase + 0, 0x00); //Null command 

120 out8(sbase + 0, Ox0E); //Send GYRO Euler Angles command 
io 


This is the command that actually starts the data 





collection. The interrupt service routine is ready to 


execute, the serial communication is set up, and the DIO is 





ready to record. Line 118 is the “Set Continuous Mode” 


command. As indicated previously, this alerts the 





MicroStrain sensor to change the output mode based on the 
next two characters received. If the mode needs to be 


changed, a null command must follow the command. The sensor 





now knows that it must continuously output the data the next 





command received indicates. Line 120 is the command for the 





gyro-stabilized Euler angles. This command indicates to the 
sensor to continuously compute and output the = gyro- 


stabilized Euler angles of the sensor. As soon as the 





sensor takes the reading and sends the first character of 
data back over the RS-232 line, the UART receives the 
character and flags an interrupt, indicating the buffer has 


a character to be taken. 


Once the sensor is outputting data and the interrupts 


are occurring, the only task the main routine is responsible 








for is letting the user know the program is still executing. 


This is performed by the following code: 





66 while (DataIndex<DataSetSize) 

67 { 

68 if (checksum==dataid+rolltpitchtyaw+timerticks) 
69 { 

70 cout<<"Its good data"<<endl; 

FA } 
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FZ else cout<<"BAD DATA! !!!"<<checksum<<" 
"<<dataid+trollt+tpitchtyawttimerticks<<endl; 
73 p 





This is simply a while loop that will loop until enough 











data has been collected by the interrupt service routine. 





The DataIndex variable is incremented every time the 








interrupt service routine has received a full set of valid 





data. For this application, a valid set of data is a set of 


11 characters from the MicroStrain sensor that represent one 








set of Euler angles. The checksum is a global variable that 
is used to verify the correctness of the data set. This 
procedure is explained in the MicroStrain section of this 





paper. The if statement verifies if the most recent data 
collected is valid. If the data is valid the program will 


output to the console “Its good data.” This indicates to 





the user that the program is still operating and the data 


being collected is valid. If the data is not valid, meaning 





all the characters collected do not equal the checksum when 








added together, then the console will output “BAD DATA!!!!” 














A bad data output to the console could mean the data is bad 
for various reasons. The checksum and the character 


addition are also output to the console if the data is 











invalid. The user is then able to verify why the data is 
invalid. When the while loop is exited, the main function 
is responsible for stopping all operation and detaching the 


interrupt. 
76 StopCONTmode () ; 
ia InterruptDetach (isr4handid) ; 
78 FileOutput (); 


As explained previously StopCONTmode() sends commands 
to the MicroStrain sensor that halts all continuous output. 


This will also cease the interrupts from occurring on IRQ 4. 








Line 77 detaches whichever interrupt handler id is sent to 
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aioe In this code it is the handler id assigned to 
isr4handid when the interrupt was initialized. The final 


major task performed in the main function is FileOutput(). 





This function outputs all the data for each sensor ina file 
that is capable of being read by MATLAB. The function 
definition is seen here: 


130 void FileOutput (void) 














131 ¢{ 

132 float myoutf; 

i332 FILE* myfile; 

134 

135 myfile=fopen ("NewEncoder23.m","wt") ; 

136 forintf (myfile, "Encoder=["); 

137 for(int i=0;i<DataSetSize;itt) 

138 { 

139 fprintf (myfile," @d\n",EncoderValue[i]); 

140 } 

141 forintf(myfile,"]';"); 

142 

143 fprintf (myfile,"\n\nMicroStrain=["); 

144 for(int i=0;i<DataSetSize;itt) 

145 { 

146 myoutf=( (float) rollnums [i]) *360.0/65536.0; 

147 fprintf(myfile," %f\n",myoutf); 

148 } 

149 forintf(myfile,"]';"); 

150 } 

This starts by creating a new file. Line 135 opens a 

new file with the name in the string parameter. The file 
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must end with an “.m” to be directly compatible with MATLAB. 
The “wt” parameter creates a new file if a file with the 
given name does not exist. If the file exists, the file is 
opened and its contents are erased. In either case the file 
is opened for reading and writing. In this code only a 
write operation is performed. myfile is an output stream 
leading to the file indicated. The information from the 
sensors must be output as an array for easy import into 
MATLAB. This means the array must be declared in the file 
in such a way that MATLAB will understand. Line 136 is the 


start of the array. The string is sent to the myfile stream 
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which will write it to the file. The for loop continues to 





output the encoder data from the encoder data array on the 





computer. When the data is completely transferred to the 


file, a “]’;” must be output to indicate the end of the 





array for MATLAB. The function continues by outputting the 
MicroStrain sensor data in the same fashion. The only major 


difference is the inclusion of line 146. This instruction 





converts the raw data of the sensor into a usable angle. 





Since there are 360° in a circle and the sensor has 16-bits 
of accuracy, the raw data must first be multiplied by 360 
and then divided by 2°° or 65536. The Euler angle is then 


output to the file. When the encoder data was output in the 








same fashion the data was truncated to the 10°’s place for 
an unknown reason. This is the reason why only the 
MicroStrain sensor data was output. When the data is 
imported into MATLAB, the encoder data must be converted to 
angles in the same fashion for an accurate analysis between 


the two sensors. 


The final lines of the main function output “Done” to 





the console to indicate to the user the data has been 


written to the file, the program is finished executing, and 





the data may be analyzed by MATLAB. The last line returns a 


1 to indicate successful operation of the function. This is 


only included because main is of type int. The code is seen 
here: 

ee) 

80 cout<<"Done"; 

81 return 1; 

82 } 
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2. The Interrupt Service Routine 


The interrupt service routine is the function that is 





executed every time the associated interrupt occurs. It is 





executed by the interrupt handler. This sequence of events 
is discussed in the previous section. It is very important 
that the interrupt service routine, ISR, execute as quickly 
as possible. No extraneous code or unneeded processing must 
be performed in the ISR. It has been discovered that the 


interrupt service routine, under the specific conditions, 





operating system, and PC104 used in this project, must not 





contain any floating point operations. Floating point 
operations cause the PC104 and the QONX OS to lock up anda 
hard reset is needed to continue any further use of the 
computer. The reason may be that floating point operations 
are very time intensive causing the interrupt service 
routine execution time to be large enough that a new 


interrupt interrupts its own interrupt service routine. 


The basic function of the ISR is to read characters off 
the UART receiver buffer, read the encoder after the last 


character is received, piece together the corresponding data 





from the UART and finally save all data in arrays for each 


sensor. 





The first lines of the code are here: 


16 int isr4 routine() 

17 { 

18 if (SerialBit<1l1) SerialBuffer[SerialBit]=in8(sbase + 0); 
//read a character off buffer 


The basic idea here is that if the index of the 


character being received from the UART buffer is less than 








11, meaning the full data packet has not yet been received 


from the MicroStrain sensor, the character recorded in the 
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SeriaBuffer array, at the appropriate index. When a 





character is read off the buffer the UART interrupt is reset 


and waits for another character. Continuing the routine: 
























































19 if (SerialBit==10) //Get all Encoder Data and calc roll pitch 
and yaw 

20 { 

ain SetOEBits(0,1);//OE1 Low 

22 while(in8 (base + 9) & 1) {} 

23 SetOEBits(1,1);//OE1 High 

24 //1.8us 

25 SetOEBits(0,1);//OE1 Low 

26 while(in8 (base + 9) & 1) {} 

27 EncoderValue [DataIndex]=in8 (base + 8); //read LSB 

28 SetOEBits(1,1);//OE1 High 

29 //1.6us 

30 SetOEBits(1,0);//OE2 Low 

31 while(in8 (base + 9) & 1){} 

32 EncoderValue [DataIndex]=EncoderValue [DataIndex]+in8 (base 
+ 8)*256; //read MSB 

33 SetOEBits(1,1);//OE2 High 

34 

35 calcnewnums (); 

36 } 





This section of code is where the encoder is latched 


and read. It is only executed when all the bytes of the 





MicroStrain sensor have been received first; when 
SerialBit==10. It is recorded after the last character is 


received because the time from the MicroStrain sensor 








position latch and the last character output is known. This 
means the encoder data can be shifted by a known amount to 
match encoder position to MicroStrain sensor position almost 
exactly in time. The code above is the recoding sequence of 
the 16-bit encoder, as discussed in the section on the 
encoder. SetOEBits gives the program a way to indicate 
which byte of data is needed and also when to latch the 
encoder position. OE1 is actually taken low then high twice 


in this code. It was discovered that the value outputted by 








the encoder is actually the value that was latched one latch 
previous. This means to get the position of the encoder at 


the exact time it was read the encoder has to be latched 
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twice to get the correct data. If the encoder is not 


latched twice the data for the current position will not be 








outputted until the next read. The data outputted at the 





current read will be the data for the position at the 








previous read. The reason for this is unknown, however, it 


was proven that the data outputted was the previous data 





latch’s position. The intermixed while statements poll the 


port B DIO looking for DA of the encoder to go low. As soon 





as this happens the data on the data lines from the encoder 


become valid and may be read. The time between lines of 








code seen in comment at line 29 is enough time to satisfy T2 


and T3 of the encoder timing diagram. Further delay is not 





necessary for the encoder to function properly. The least 
Significant byte of the position is read first, followed by 
the most significant byte. This is the reason the data read 


in line 32 is multiplied by 256 and then added to the least 








Significant byte. The data is stored in the EncoderValue 
array. This array holds all the successive encoder 
readings. When the encoder is finished reading, the 


MicroStrain sensor data is then converted into useable 
numbers by calcnewnums(). The code for this function is 


seen here: 


103 void calcnewnums (void) 














104 { 

105 dataid=SerialBuffer[0]; 

106 roll=SerialBuffer[1]*256 + SerialBuffer[2]; 
LOF if (roll>=32768) roll=(-1) * (65536-roll); 

108 pitch=SerialBuffer[3]*256 + SerialBuffer[4]; 
109 if (pitch>=32768) pitch=(-1) * (65536-pitch) ; 

LAO yaw=SerialBuffer[5]*256 + SerialBuffer[6]; 

i i a8 if (yaw>=32768) yaw=(-1) * (65536-yaw) ; 

ie timerticks=SerialBuffer[7]*256 + SerialBuffer[8]; 
cli ee) checksum=SerialBuffer[9]*256+SerialBuffer[10]; 
114 } 


This function combines and stores the current roll, 


pitch, and yaw Euler angles from the MicroStrain sensor in 
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respective variables. The dataid should be the code for the 
data requested. In this case it is 14 or OxOE. The roll, 


pitch, and yaw data most significant bytes and least 





Significant bytes are combined into one number to represent 
each angle in a 16-bit form. The data outputted by the 
sensor is in two’s compliment form. The if statement 
converts the numbers from a two’s compliment into a signed 


integer form for ease of conversion to degrees later. 


The interrupt service routine then continues by 
increasing the SerialBit variable by 1. This is used to 
track the number of characters taken off the buffer for the 


current data pack: 





37 SerialBit++; 

38 if (SerialBuffer[0]!=14) SerialBit=0; //reset because of 
invalid data 

39 if ((SerialBit==11) && (DataIndex<DataSetSize) ) 

40 { 

41 SerialBit=0; //rollover for next data set 

42 rollnums [DataIndex]=roll; 

43 DataIndext++; 

44 } 

45 

46 return 1; 

47 } 


The if statement in line 38 will reset the data pack if 





the first character received is not a 14, or Ox0OE. It is 
expected that the first character of every new data packet 
will be this value because of the standard set by the 
MicroStrain sensor. The first set of the data packet sent 


will be command code for the data requested. In this 





project, the gyro-stabilized Euler angles are requested for 


which the command code is Ox0OE. If the ISR places any 





character other than a O0x0OE in the first index of the buffer 
array the index is reset. This will happen until Ox0E is 


found in the first index of the buffer. At this time, the 
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ISR knows that it is the start of a new valid data pack and 


will allow the index to increment. 





Line 39 starts the routine if a complete data packet 


has been received. In this case the SerialBit should be 11, 





indicating 11 characters were read off the buffer, and the 














current data packet index is less than the size of the data 











set requested. If the while loop in the main function does 





not exit and the interrupt detached, it would be undesirable 
for data to continue to be recorded. When DataIndex is 


equal to or greater than DataSetSize, the ISR knows that all 





th requested data has been processed and recorded; no 


further data is needed. Line 42 records the roll angle of 





the current reading into the array that will be output to 








the file later. Finally, the index of the data is 





incremented so when the ISR records the next set of data it 





will be placed in the next element of the two arrays. The 





ISR returns a 1, meaning the interrupt was processed 


correctly. 


3. 10-Bit Encoder Program Differences 


There were a few differences between the 16-bit encoder 











program described previously and the 10-bit encoder program. 
The main difference was the data collection method. The 10- 
bit encoder program used the polling method of MicroStrain 


data collection. This method is useful for a non- 





deterministic application, but for this application, the 





tim between readings needs to be exact. The other 


difference was that the encoder was read when the request 





for data was sent out. This means the time difference 


between th returned data from the MicroStrain sensor and 








th ncoder reading could be anywhere from 0-13ms_ of 
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difference. The sensor would receive the request sometime 





during the current calculation cycle and then output that 
data. Since there is no way of knowing where in the 


calculation cycle the sensor is, there is no way of 











determining the time between the encoder reading and the 


sensor reading. 


Another major difference in the two programs is the 
reading method of the encoder. Since the 10-bit encoder 


outputs data in a parallel method and there is minimal 











calculation time, the data from the encoder can be read all 


at once. This means the DIO of the PC104 reads all 10 bits 











at once. The 8 least significant bits are on port A and the 
2 most significant bits are on port B. The data collected 
by the PC104 from the encoder will also have to be converted 





before output to the file. This is because the encoder 





outputs in grey code. This must be converted to a binary 


number and then converted to the final respective degre 





Cc. RESULTS 


Many tests were performed. They included testing the 
10-bit encoder at a pendulum length of two feet, 16-bit at 


one, two, and three foot lengths, and the pitch and yaw 





angles of the 16-bit encoder at a two foot length. The 


results were all very similar. There were definite 








characteristics present that were expected, but also some 
that were newly discovered. All of the results proved the 


3DM-GX1 sensor does have the capability of operating within 





the specifications put forth by the MicroStrain company, 





under the speed conditions tested. A faster moving sensor 





may produce a larger error. Since the MicroStrain sensor 








and the encoder zero positions do not match, the test was 
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started at the zero position for the first approximately 100 
time samples and then the pendulum was put into motion. 
This period of no motion at the zero point allows the 
possibility to match the data up, based on this zero 
position. When the data is imported into MATLAB the mean of 


this rest period is taken for each data set. The mean is 





then subtracted from each data point to align the two 





sensors around zero degrees. The result of this is two sets 
of data that track the same degree position over time. 


After this, the error between the two sensors can be 





calculated. This procedure is performed for every plot of 


the data sets in this section. 


The results from the 10-bit encoder can be seen in 


Figure 14. 
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10-Bit Encoder and 3DM-Gx1 
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Figure 14. 


10-Bit Encoder and 3DM-GX1 Sensor Results. 
The absolute difference is magnified by a gain of 20 in 
the plot. 


This test was performed by allowing the pendulum to 


rest at the zero point for about 100 samples. The pendulum 


was then lifted and released by hand. The data collected 


with this sensor indicated that the largest error was only 


<e507 This occurred at sample 867. The “Absolute 


Difference” is the absolute value of the difference between 





the readings of the two sensors for the same sample. The 


value is then multiplied by a gain of 20 so it would be 


easier to analyze on the same plot as the data. The mean 





line is the mean of this difference over the entire sample 


set. This line is there for reference purposes of the 
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difference data. The MicroStrain sensor data in this 
example is shifted to the left by one sample. The method of 


data sampling used for this data collection does not ensure 





that the data matches at each sample period because the 
MicroStrain sensor reading is not guaranteed. Polling was 


used, so the reading associated with the time sample has the 





possibility of being one time sample ahead of the encoder, 





N“ Ww 


in position. This means at time “x”, the encoder was at the 


correct position, but the MicroStrain sensor reading at time 


NN aw 


x” could be the reading that was supposed to be associated 


with time “x+l” of the encoder. This problem was solved 





with the 16-Bit encoder because the data collection was more 








deterministic and accurate. Another problem with the data 
collected by the 10-Bit encoder is the relation between the 


test bench, the encoder, and the MicroStrain sensor. 








The test bench must have 16-bits of accuracy or 





better since the MicroStrain sensor has this degree of 
accuracy. The limited resolution of the 10-bit encoder is 


the cause of the stair characteristic of the zoomed view of 











the results plot in Figure 15. This was the motivation to 





move to the more accurate 16-bit absolute encoder. 
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10-Bit Encoder and 3DM-Gx1 


T T T T T 
| * Encoder 
*  3DM-GxX1 
Absolute Difference 
Mean Line 














Degrees 











| 
145 160 165 160 165 
Sample 


Figure 15. Zoomed View of 10-Bit Encoder and 3DM-GX1 
Results. 


The MicroStrain sensor was tested at three different 
lengths, one foot, two feet, and three feet. All of these 
results had very distinct characteristics that were more 


well defined in each test. All of the plots from this point 








on were generated in MATLAB using the same process. The 
major point that must be realized is the shift of the 


encoder data. 


The data in the 10-bit encoder example was shifted, as 
it was for the 16-bit encoder, but the shift in the 16-bit 


encoder was much more accurate. The basic process of the 





MicroStrain sensor computation is to read all of the 


sensors, convert to a digital value, perform Euler 





calculations, and finally output on the RS-232 line. This 
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process repeats continuously as long as the sensor is 
powered on and the command signal requests the Euler angles. 
The sensor deterministically starts a new calculation every 


13.107ms. Therefore, it is known with relative assurance 





that at approximately the time the last character of the 


data is sent out of the sensor the next calculation is 





started. The sensor is read at the beginning of the cycle 
and the encoder is latched at this time. Thus, it can be 
Said with relative assurance that the encoder position is 
13.107ms later than the corresponding MicroStrain position, 
Since This means the encoder position must be shifted back 
by 13.107ms to relate the positions at the exact time 


instead of the corresponding sensor sample. The position of 








the encoder does not have to be estimated at the time which 





is 13.107ms in the past, though, because it is known that 


the previous encoder position read was exactly 13.107ms in 








the past because the calculation cycle time of the 


MicroStrain sensor that is driving the data collection is 





13.107ms. The un-shifted data can be found in Figure 16. 
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Unshifted Data 
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Figure 16. Un-shifted Encoder and MicroStrain Sensor 
Data. 


The un-shifted data is the data that is received 




















without the time correlation shift. It can be seen that the 
corresponding data has a gap of one time sample. The 3DM- 
GX1 data reaches a certain degree one time sample later than 





the encoder data. This time sample is the 13.107ms 
difference described earlier. To better analyze this data, 


the data must be shifted first. 





In this project, instead of shifting the encoder 
position back 13.107ms in the past, the MicroStrain sensor 
data is shifted to correspond to the encoder data. This is 
accomplished by shifting the entire MicroStrain sensor data 


one index to the left, effectively matching the currently 
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calculating sensor position with the encoder position at 


This erases the effect of the calculation 





that same time. 
cycle delay at the expense of loosing the first MicroStrain 


sensor data point read by the system. Once this data is 


matched up by time instead of sample, the data can be 


analyzed more accurately. This is exactly what was done in 


all of the following examples. The following plots are the 





one, two, and three feet test results. 


One Foot Pendulurn 
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Figure 17. One Foot Pendulum Data. The absolute 





difference is multiplied by a gain of 20. 





The data in the above plot is the data for the system 


when the pendulum is one foot in length. The mean line in 
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this and all the following plots is the mean of the error. 





It was included to serve as a reference point for the error 
analysis. Accounting for the fact that the error is scaled 
by a gain of 20, is can be seen that the error is above 1° 
at various time points. The largest error is 1.3019° at 
sample 215. This error is within the specification of the 


MicroStrain sensor. The magnitude of the error also follows 





the expected pattern. It is expected that when the pendulum 








is moving the slowest there should be the least amount of 


error. This is because as the pendulum slows down, it 
approaches a static state. The static accuracy magnitude of 
the sensor is less than 0.5° of error. The position where 








the pendulum is the slowest is when it is changing direction 





at the extremes. Looking at the above plot, it can be seen 








that this is exactly what happens, as the pendulum 


approaches the maximum or minimum the error approaches 0. 


Another curiosity observed is that the error is 
actually almost a direct function of the velocity. This can 


be observed in Figure 18. 
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Figure 18. Zoomed View of One Foot Plot. The velocity 
has a gain of 20 and the absolute difference has a gain 
ef 60. 


In this plot, the absolute value of the error is not 


The error data is the actual error, 





this time scaled 
tch 


taken. 


by 60, not 20. This scale was used to more closely mat 


The velocity is the plot of the 


This was found by taking the 
is the 


the peaks of the curves. 


velocity of the encoder curve. 








derivative of the encoder curve because velocity 





derivative of position. The derivative curve in the plot 


also has a gain of 20. This was used to match the tops of 


could be performed. In 
the 


the curves so a visual analysis 





the derivative curve is much smaller because 
This plot indicates 


reality, 








gradient function in MATLAB was used. 


that the equation for the error may not be the velocity 
exactly, but it is very similar. The exact reason for this 


error is not known. 
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Two Foot Pendulum 
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Figure 19. Two Foot Pendulum Data. The absolute 


difference is multiplied by a gain of 20. 





The two foot plot is very similar to the one foot plot. 
This two foot plot can be found in Figure 19. The recorded 
max error is much better though. The max error is .7459° at 


sample 561. This is again within the specifications for the 





MicroStrain sensor. This is most likely because the 
pendulum is moving slower. As the pendulum length 
increases, the speed of oscillation decreases. Holding the 


correlation discovered for the previous test, this is what 
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was expected; the slower the velocity, the more accurate the 


There is one slight difference though. There is 
A 


readings. 
a small camel back at the peaks of all the error curves. 


more pronounced view is seen in Figure 20. 
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Figure 20. Zoomed View of Two Foot Plot. The velocity 
has a gain of 20 and the absolute difference has a gain 
pi 60. 


The camel back could be caused by two possible effects. 
It is possible that the acceleration has a small part in the 
equation for the error. This would account for the camel 


back because at the camel backs, the acceleration is zero. 





The acceleration would have to be inversely related to the 


velocity. That is, when the velocity magnitude is greater, 


the acceleration would have less of an effect. This would 








account for the differences between this plot and the plot 
of the one foot test. In the one foot test the velocity is 


greater, meaning the acceleration has less of an impact. 
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This would allow the one foot curve to be smooth and the two 


foot curve to have a little camel back when the acceleration 





1s zero. 


The second cause of the camel back could be due to the 


flexure of the pendulum shaft. The shaft is made from wood 





and has a small spring characteristic in it. As the 





pendulum swings the shaft may flex slightly. The longer the 








pendulum, the larger the flex. The flex would also be 
periodic because of the spring like characteristic of wood. 


When the wood is flexed in one direction it will reverse the 





flex in the other direction when the force holding the flex 


is overcome. This motion would create a periodic motion, 





which is exactly what the camel back is. If this is the 


cause of the camel back, the camel back found here should be 





more pronounced in the three foot test, because the pendulum 


is longer and has more ability to flex. 


The three foot test results can be seen in Figure 21. 
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Figure 21. Three Foot Pendulum Data. The absolute 





difference is multiplied by a gain of 20. 


The maximum error for the three foot test is .6820° at 
sample 984. Once again, as can be expected, the sensor 
error is well within the MicroStrain specifications. The 


plot clearly shows the MicroStrain sensor’s position very 








closely matches the encoder position for the entire path of 


motion. There is some peculiarity in this plot as well 
though. In this plot the error data does not seem to have 
much correlation to the position at all. It certainly does 


not have any correlation to the velocity, as seen in Figure 


22. 


95 


Three Foot Pendulum 





I 
Encoder 4 
*  3DM-Gx1 


Absolute Difference 
—-—- Zero Line = 


— — Velocity 
Acceleration 




















Degrees 


x 
Nes. 
! 














Sample 


Figure 22. Zoomed View of Three Foot Plot. The velocity 
and the acceleration both have a gain of 20 and the 
absolute difference has a gain of 60. 


On the above plot, the acceleration was plotted. This 


is the second derivative of position and in this plot the 








second derivative of the encoder data. A gain was applied 
to the curve for visual analysis. A mean filter was also 
applied to the curve to make it smoother. The filter took 





the average of a point and the one immediate point on each 
side of it to create a new point. This process was applied 
to every point which resulted in a much smoother curve. It 
is very peculiar that error curve for this length is very 
Similar to the acceleration curve of the pendulum. This is 


what was expected though, based on the theories developed 





with the one and two foot tests. The differences between 





the acceleration curve and the error curve are relatively 





small, suggesting a relationship. The differences could be 


due to the flexure of the rod as discusser earlier. 


The overall results indicate that the error of the 





MicroStrain sensor is very likely a function of the 
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velocity, acceleration, and flexure of the pendulum rod. 
The faster the pendulum moves the more influence the 


velocity has. As the movement of the pendulum slows, the 





acceleration starts to have more of an influence on the 





error. The longer the pendulum, the more flexure and 


associated error influence. The error from the one foot 





test to the three foot test seems to have a logarithmic 
property. This could be caused by the changes in factors 
influencing the error. This may also be a clue to the 


relationship of acceleration, velocity, and flexure to the 











error of the MicroStrain sensor. It also indicates the 
possibility of the MicroStrain sensor error eventually 


becoming larger than the specifications indicate. The exact 








point where this may occur is not known because there is no 


formula for the error relationship, only clues that could 








eventually lead to one. It is also possible that the error 


will remain within specifications until the sensor’s motion 











moves outside the maximum angular rate specification of the 








sensor. At this point it is expected that the error and 





other measurements will not be accurate. 





97 


THIS PAGE INTENTIONALLY LEFT BLANK 


98 


Vv. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 


The purpose of this project was to develop a control 
systems environment complete with encoder capabilities on a 


PC104. The system capabilities were tested by using it to 





measur th dynamic accuracy of the MicroStrain 3DM-GX1 





orientation sensor against the benchmark of an encoder. The 
digital input/output and the digital-to-analog conversion 
circuits and the RS-232 port of the PC104 were used to 


accomplish this task. 


In this project, a Diamond Systems Prometheus PC104 
with a data acquisition circuit was used as a target 
machine. The main encoder used was a 16-bit absolute 
encoder by Gurley Precision Instruments. The encoder 
communication and control was performed with the digital 
input/output circuit. The MicroStrain 3DM-GX1l _ sensor 
communications all occurred through the RS-232 port. The 


MicroStrain sensor was attached to the end of a wooden 








pendulum and th ncoder served as the pivot point of this 
pendulum. This allowed the angles of the two sensors to 
move synchronously with one another. The pendulum was set 





in motion and the position of the two sensors were recorded 


and outputted to a MATLAB compatible file. 


The results yielded an error of the MicroStrain sensor 
well within the specifications established by the company. 


The worst error was 1.3019° when the pendulum was at a 
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length of one foot. It was discovered that the error is a 





function of the velocity, acceleration, and flexure of the 





pendulum. 


B. RECOMMENDATIONS 


Further work would be deriving an error equation for 
the MicroStrain sensor. This would be useful in any 
application that uses this sensor because it may allow the 
user to compensate for the error, virtually erasing it. An 
encoder board could also be added to the PC104 system to 
allow interaction with the incremental encoder and multiple 
encoders at once. The system also can be used to test the 


dynamic accuracy of other inertia-based orientation sensors. 
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APPENDIX A: 16-BIT ENCODER C++ CODE 


#include <control/control.wse> 


#define sbase 0x3F8 

int SerialBit, DataIndex, DataSetSize; 

int roll,pitch, yaw, dataid, timerticks, checksum; 
void SerComInit (void); 

void calcnewnums (void) ; 

volatile signed rollnums[100000]; 

volatile signed SerialBuffer[11]; 

volatile signed EncoderValue[100000]; 








void SendInstantEulerAngleCONT (void) ; 
void StopCONTmode (void) ; 

void FileOutput (void); 

void SetOEBits(int,int); 





16 int isr4 routine() 


Ly 
18 


19 


20 
21 
22 
23 
24 
25 
26 
21 
28 
29 
30 
31 
a2 


33 
34 
3:5 
36 
37 
38 


39 
40 
4] 
42 
43 
44 
45 
46 


if (SerialBit<11) SerialBuffer[SerialBit]=in8(sbase + 0); 
//read a character off buffer 


























if (SerialBit==10) //Get all Encoder Data and calc roll pitch 
and yaw 
{ 
SetOEBits(0,1);//OE1 Low 
while (in8 (base + 9) & 1) {} 
SetOEBits(1,1);//OE1 High 
//1.8us 
SetOEBits(0,1);//OE1 Low 
while (in8 (base + 9) & 1) {} 
EncoderValue [DataIndex]=in8 (base + 8); //read LSB 
SetOEBits(1,1);//OE1 High 
//1.6us 
SetOEBits(1,0);//OE2 Low 

















while(in8 (base + 9) & 1){} 

EncoderValue [DataIndex] =EncoderValue [DataIndex] +in8 (base 

+ 8)*256; //read MSB 
SetOEBits(1,1);//OE2 High 

















r. 








calcnewnums () ; 
} 
SerialBit++; 
if (SerialBuffer[0]!=14) SerialBit=0; //reset because of 
invalid data 
if ((SerialBit==11) && (DataIndex<DataSetSize) ) 
{ 








SerialBit=0; //rollover for next data set 
rollnums [DataIndex]=roll; 
DataIndextt+; 

} 


return 0; 
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} 


int 


{ 


main () 


BoardInit () 


out8 (base + 11, OxXxFE); 





Output 
outs (base+10,0x03);//OE1 OE2 high 


ak 


/*in 
eS 
el 

void 


{ 


SerialBit=0; 
DataIndex=0; 
DataSetSize=1000; 





SerComInit(); 
StopCONTmode () ; 
ISR4Init(); 





//set all DIOA DIOB to input DIOClow 





SendInstantEulerAngleCONT () ; 


while (DataIndex<DataSetSize) 


{ 


if (checksum==dataid+rollt+pitchtyawttimerticks) 


{ 


cout<<"Its good data"<<endl; 


} 


else cout<<"BAD DATA!!!!"<<checksum<<" 
"<<dataidtrolltpitchtyawttimerticks<<endl; 


} 


//stop continuous mode 


StopCONTmode () ; 


InterruptDetach (isr4handid) ; 


FileOutput (); 
cout<<"Done"; 
return 1; 

isr_ routine (void) 


return 0; 





itialize COM with 
84000 baud 
,N,8 * / 

SerComInit (void) 
out8(sbase + 4, 0x09 
out8(sbase + 3, 0x83 
out8(sbase + 0, 0x03 
out8(sbase + 1, 0x00 
out8(sbase + 3, 0x03 
out8(sbase + 2, 0x07 
out8(sbase + 1, 0x15 








//MCR data terminal ready 
//enable latch for baud rate set 
//lower baud divisor 

//upper baud divisor 

//disable latch, 1,N,8 

//set FIOF to 1 character 
//enable recv interupt 
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106 
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aes 
2 
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aS 
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121 
22 
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134 
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136 
Lo 
138 
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140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
Bil 
152 
153 
154 
155 


} 


void calcnewnums 


{ 


(void) 


dataid=SerialBuffer[0]; 

roll=SerialBuffer[1]*256 + SerialBuffer[2]; 

if (roll>=32768) roll=(-1) * (65536-roll); 
pitch=SerialBuffer[3]*256 + SerialBuffer[4]; 

if (pitch>=32768) pitch=(-1) * (65536-pitch) ; 
yaw=SerialBuffer[5]*256 + SerialBuffer[6]; 

if (yaw>=32768) yaw=(-1) * (65536-yaw) ; 
timerticks=SerialBuffer[7]*256 + SerialBuffer[8]; 
checksum=SerialBuffer[9]*256+SerialBuffer[10]; 





} 

















void SendInstantEulerAngleCONT (void) 


out8(sbase + 
out8(sbase + 
out8(sbase + 





0, Ox10); //Command command 
0, 0x00); //Null command 
0, Ox0E); //Send GYRO Euler Angles command 








void StopCONTmode (void) 


out8(sbase + 
out8(sbase + 
out8(sbase + 





0, Ox10); //Command Command 
0, 0x00); //Null Command 
0, 0x00); //Null Command 





void FileOutput (void) 


{ 
float myoutf 





, 


FILE* myfile; 


myfile=fopen 





("NewEncoder23.m","wt"); 


forintf (myfile, "Encoder=["); 
for(int i=0;i<DataSetSize;it+t) 


{ 








fprintf (myfile," d\n",EncoderValue[i]); 


} 


fprintf(myfile,"]';"); 


fprintf (myfile,"\n\nMicroStrain=["); 
for(int i=0;i<DataSetSize;it+t) 


{ 
myout f= ( 


(float) rollnums[i])*360.0/65536.0; 


fprintf(myfile," %f\n",myoutf) ; 


} 


fprin tf (myfile, wa ' 7) ; 


} 





void SetOEFBits(int OF1, int OE2) 











{ 











out8 (base+10, (OE1 + 2*OE2)); 


} 


THIS PAGE INTENTIONALLY LEFT BLANK 
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inc 
inc 
inc 
inc 
inc 


APPENDIX B: CONTROL.WSE CODE 


lude <cstdlib> 
lude <iostream> 
lude <stdlib.h> 
lude <stdio.h> 


lude <iomanip.h> 





inc 
inc 
inc 
inc 
inc 








def 


lude <time.h> 
lude <unistd.h> 





lude <math.h> 





ine base 0x280 


lude <hw/inout.h> 
lude <sys/neutrino.h> 


volatile unsigned nums[100000]; 





volatile unsigned isrhandid; 








Dconversion (void); 


char* ,. int). 
int, int); 





t,int,int,int,int); 








terrupt (void) ; 














t* isr4 handler(void*, int); 


r4handid; 


int frequency; 

int BoardInit (void); 

int waitforA 

int waitforADsettle (void); 
int DAcheckstatus (void) ; 
int SendDAC(int , float); 
float GetADVolts(int, int); 
int fileoutput (const 

int TimerOInit(int , 

int TimerOStart(); 

int SetFIFOThreshold(int); 
int ADInit(int,in 

int ClearAnalogIn 

int ResetFIFOdepth (void) ; 
int isr routine (void); 

int Binary2Dec(int,int); 
int* Grey2Binary(int,int); 
int* DIO2Grey(int,int); 
int PortAin(void); 

int PortBin(void); 

void SetAl1DIO(int); 

const struct sigeven 

int isr4 routine (void) ; 
int int4; 

volatile unsigned is 

int ISR4Init (void) ; 

// This must be run 








to get root permission at access hardware 


// It also resets the data aquisition board, everything except the 
DAC output 
int BoardInit (void) 


{ 








int privity err; 
privity err=ThreadCtl( NTO TCTL IO, NULL ); // thread gets 
root permission at access hardware 
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} 


if (privity _err==-1) 


{ 


cout<<"can't get root permission"; 
return -1; 


} 


out8 (base + 0, 0x40); //reset the board, 


return 1; 


except the DAC output 


// This function waits for the AD conversion to happen 
// Returns 0 if successful 
// Reutrns -1 if timed out 
int waitforADconversion() 


{ 


} 


int i; 


for (i=0;1<10000;i++) 


{ 


if(!(in8 (base + 3) 


} 


return -1; 


& 0x80) ) 


return 0; 


// This function waits for the AD circuit to settle out\ 
// Returns 0 if successful 
// Returns -1 if timed out 
int waitforADsettle() 


{ 


} 


inte 2; 


for (i=0;1<10000;i++) 


{ 


if(!(in8 (base + 3) 


} 


return -1; 


& Ox20) ) 


return 0; 


// This loops until the DA conversion is completed 
// Returns 0 if successful 
// Returns -1 if timed out 
int DAcheckstatus () 


{ 


} 


int i; 


for (i=0;1<10000; i++) 


{ 


if(!(in8 (base + 3) 


} 


return -1; 


& Ox10)) 


return 0; 


// Output a voltage volts on channel chan 


int SendDAC (int chan, 


{ 


int DAlevel; 
int DAref=10; 
if (volts<-10) 
if (volts>10) 


volts=-10; 
volts=10; 


float volts) 
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DAlevel=chan*16384+ (volts*2048) /DAref+2048; 
outl6(base + 6, DAlevel); 

DAcheckstatus(); 

return 1; 


} 





float GetADVolts(int chan, int gain) 
{ 
int ADvalue; 
float voltage; 
out8 (base + 2, chan*16 + chan); //set the channel range 
out8 (base + 3, 4*1 + gain); //set scan mode and gain 
waitforADsettle(); 
out8 (base + 0, 0x80); //start AD conversion 
waitforADconversion(); 
ADvalue=in8 (base + 0) + in8(base + 1) * 256; 
if (ADvalue<32768) voltage= .0000152587890625 * 20 * ADvalue; 
else voltage=.0000152587890625*20 * ADvalue - 20; 
return voltage; 





} 


int fileoutput (const char* filename, int numsamples) 
{ 

FILE* myfile; 

float voltage; 

myfile=fopen (filename, "wt") ; 

fprintf (myfile, "Hello=["); 

for(int i=0;i<numsamples;itt) 


{ 








if (nums[i]<32768) voltage= .0000152587890625 * 20 * 
nums [i]; 
else voltage=.0000152587890625*20 * nums[i] - 20; 
fprintf(myfile," %f\n",voltage) ; 
} 
fprintf(myfile,"]';"); 
return 0; 


} 


//This function initializes TimerO with a corrected frequency, 
rounding 

//up to the next highest divisor of the input clock 

//freq is desired frequency, input is clock source, gating will 
enable the gating 

//input: 0=10Mhz 1=1Mhz; 

int TimerOInit(int freq, int input, int gating) 


{ 











long workingl,working2,entry; //workingvalues 
int hexout[3]; 

int regstat; 

entry=10000000/freq; 
frequency=10000000/entry; 

for(int i=0;1i<3;i++) 

{ 





workingl=entry/pow(16.0,2.0%*i); 
working2=entry/pow(16.0,2.0*it2); 
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} 


{ 


} 


hexout [i] =working1-256*working2; 
} 
regstat=(in8 (base + 4) & 0x20) / 0x20;//check clock input 
if (regstat!=input) //if clock input is not what is desired 


{ 





if (input==1) out8(base + 4, (in8(base + 4)) + 0x20); //set 
it to 1Mhz 
else out8(base + 4, (in8(base + 4)) - 0x20); //set it to 
10Mhz 
} 
out8 (base + 12, hexout[0]); //low value 
out8 (base + 13, hexout[1]);//mid value 
out8 (base + 14, hexout[2]);//high value 
out8 (base + 15, 0x02);//load value 








//out8 (base + 15, 0x04);//start counting 


//start Counter0O, TimerOInit must be run first 
int TimerOStart (void) 


out8 (base + 15, 0x04); 


//sets the threshold of the FIFO 
int SetFIFOThreshold(int depth) 


out8 (base + 5, depth); 


int ADInit(int lowchan, int highchan, int scan, int interrupt, 


int trigger, int gain) 


int regstat,input; 
if (lowchan>highchan) cout<<"Error: The AD high channel is 
lower than the low channel"<<endl; 






































else if ((lowchan<0O) || (lowchan>15)) cout<<"Error: The AD low 
channel is either less than 0 or greater than 15"<<endl; 

else if((highchan<0) || (highchan>15)) cout<<"Error: The AD 
high channel is either less than 0 or greater than 15"<<endl; 
else if ((scan<0O) || (scan>1)) cout<<"Error: The AD scan value is 
invalid"<<endl; 

else if((interrupt<0) || (interrupt>1)) cout<<"Error: The AD 
interrupt value is invalid"<<endl; 

else if ((trigger<0) || (trigger>1)) cout<<"Error: The AD trigger 
value is invalid"<<endl; 

else if (! ((gain==1) || (gain==2) | | (gain==4) | | (gain==8) ) ) 


cout<<"Error: The AD gain value is invalid"<<endl; 
else 


{ 





out8 (base + 2, lowchan+16*highchan); //set the channel 
range 





out8 (base + 3, 4*scantlogf(gain) /log(2.0)); //set the gain 
and scan mode 
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int 


int 


int 


int 


int 


regstat=(in8 (base + 4) & 0x10) / 0x10; //check AD trigger 
source 

if(regstat!=trigger) //if trigger source is not what is 
desired 


{ 


if (trigger==1) out8(base + 4, (in8(base + 4)) + 0x10); 
//set it to external clock input 
else out8(base + 4, (in8(base + 4)) - 0x10); //set it 


to Counter0 

} 

regstat=(in8(base + 4) & 0x01) / 0x01; //check interrupt 
enable 

if(regstat!=interrupt) //if interrupt enable is not what 
is desired 


{ 


if (interrupt==1) out8(base + 4, (in8(base + 4)) + 
0x01); //enable interrupt 
else out8(base + 4, (in8(base + 4)) - 0x01); //disable 


interrupt 
} 
waitforADsettle(); //let the AD converter to settle out 
return 1; 


} 





cout<<"ADInit Error, program many not execute as 
expected"<<endl; 
return 0; 





ClearAnalogInterrupt (void) 
out8 (base + 0, 0x01); 
return 1; 

Reset FIFOdepth (void) 

out8 (base + 0, 0x10); 
return 1; 

ADvalue (void) 


return (inl6(base + 0)); 


NormADvalue (void) 
int AD; 
AD=inl6(base + 0); 


if (AD<32768) return AD; 
else return (65535-AD) *(-1); 


isrSendDAC (int chan, int output) 


Loo 


output=outputt+2048; 

if (output>4095) output=4095; 

if (output<0) output=0; 

outl6(base + 6, (chan*16384+output) ); 
DAcheckstatus (); 

return 1; 


} 


/* The hardware interrupt handler */ 
const struct sigevent* isr handler(void *arg, int intr) 
{ 
isr routine (); 
InterruptUnmask (5,isrhandid) ; 


int ISRInit (void) 
isrhandid=InterruptAttach(5,isr_ handler, NULL, 0, 


NTO INTR FLAGS TRK MSK); 
return 1; 





int ISRStop (void) 

InterruptDetach (isrhandid) ; 

return 1; 
int CheckFIFOOVF (void) 

return ((in8 (base+3) &0x08) /0x08) ; 
/*Convert a binary number into decimal*/ 


int Binary2Dec(int* Binary,int size) 


{ 








int Decimal; 
Decimal=0; 
for(int i=0;i<size;itt) 


{ 





//the Binary array member must be referenced by 
//* (Binaryti) 
Decimal=Decimal+ (* (Binaryti))* (int) (pow(2.0,1)); 











} 


return Decimal; 


} 





/*Convert a grey code number into binary*/ 
int* Grey2Binary(int* Grey,int size) 
{ 
int* Binary = new int[size]; //this is needed for proper 
return 
//Fill Binary with all 1's 
for(int i=0;i<size;it+t) 
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{ 

Binary[i]=1; 
} 
//Start Conversion 
Binary[size-1]=* (Grey+(size-1)); 
for(int i=size-1;i>0;i--) 


{ 








//Grey array must be referenced by * (Greyti) 
if (Binary[i]==(* (Grey+(i-1)))) Binary [i-1]=0; 





} 


return Binary; //return binary number 





/*convert the DIO raw number into grey code*/ 
int* DIO2Grey(int DIO, int size) 
{ 
int* Grey = new int[size]; //this is needed for the proper 
return for array 


//Strip off bits through masking 











Grey[O0]=((DIO & 1)==1); 
Grey[1l]=((DIO & 2)==2); 
Grey[2]=((DIO & 4)==4); 
Grey[3]=((DIO & 8)==8); 
Grey[4]=((DIO & 16)==16); 
Grey[5]=((DIO & 32)==32); 
Grey[6]=((DIO & 64)==64); 
Grey[7]=((DIO & 128) ==128) ; 
Grey[8]=((DIO & 256) ==256); 
Grey[9]=((DIO & 512)==512); 


return Grey; //return the grey code 


} 


/*Reads PortA*/ 

int PortAin (void) 

{ 
int read; 
read=in8 (base + 8); //read port A 
return read; 


} 


/*Reads PortB*/ 

int PortBin (void) 

{ 
int read; 
read= in8(base + 9); //read port B 
return read; 





} 


/*Set all the DIO ports to input/output, 1=in O=out*/ 

void SetAl1DIO(int inout) 

{ 
if (inout==1) out8(base + 11, OxFF); //make all DIO ports input 
else out8(base + 11, 0x00); //Make all DIO ports output 
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} 


/*IRQ 4 Handler*/ 


const struct sigevent* isr4 handler(void *arg, 


{ 
isr4 routine(); //ISR routine 
InterruptUnmask (4,isr4handid) ; 
} 


/* Initialize IRQ 4 handler*/ 
int ISR4Init (void) 
{ 


// 


Enable IRQ 4 





isr4handid=InterruptAttach(4,isr4 handler, 


NTO INTR FLAGS TRK MSK) ; 
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int intr) 


NULL, 











[13 


a 


a 


LIST OF REFERENCES 


X. Yun and E.R. Bachmann, "Design, implementation, and 
experimental results of a quaternion-based Kalman 
filter for human body motion tracking," IEEE 
Transactions on Robotics, Vol. 22, No. 6, pp. 1216- 
1227, December 2006, 





D. Churchill, “Quantification of human knee kinematics 
using the 3DM-GX1l sensor,” MicroStrain Inc., January 
2004. 





“Ampro History,” May 2007, 
http://www.ampro.com/html/Overview History.html. 





PC104 Consortium, “History,” May 2007, 
http://www.pcl04.org/history.html. 


Prometheus High Integration PC/104 CPU with Ethernet 
and Data Acquisition Models PR-Z32-E-ST PR-Z32-EA-ST 
User Manual V1.44, Diamond Systems Corporation, 2003. 





QNX Neutrino Realtime OS: Kernel Benchmark Mehtodology, 
QNX Software Systems Ltd., 2003. 





S. Furr, “What is real time and why do I need it?” QNX 
Software Systems Ltd., 2002. 


S. Arms, “MicroStrain message from the president,” May 
O07, http://www.microstrain.com/company-overview.aspx. 


“3DM-GX1,” May 2007, http://www.microstrain.com/3dm- 
gxl -specs.aspx. 


3DM-GX1 Data Communications Protocol, MicroStrain Inc., 
2005. 


SDM-GX1 Orientation Sensor Timer Ticks, Calculation 
Cycle and Data Output Rates, MicroStrain Inc., 2006. 





CP-300 Series Housed Encoders, Computer Optical 
Products Inc. 


Optical Encoder Applications, Computer Optical Products 
Inc. 


113 


[14] Gurley Model A58 Absolute Encoder, Gurley Precision 
Instruments. 


[15] “Serial UART information,” May 2007, 
http://www.lammertbies.nl/comm/info/serial-uart.html. 


INITIAL DISTRIBUTION LIST 


Defense Technical Information Center 
Ft. Belvoir, Virginia 





Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 





Jeffery Knorr, ECE Department Chairman 
Naval Postgraduate School 
Monterey, California 


Xiaoping Yun 
Naval Postgraduate School 
Monterey, California 


Matthew Feemster 
United States Naval Academy 
Annapolis, Maryland 





Douglas Fouts 
Naval Postgraduate School 
Monterey, California 





James Calusdian 
Naval Postgraduate School 
Monterey, California 


Jonathan Shaver 


Naval Postgraduate School 
Monterey, California 


115 


